How to combat "likers" that register and give likes only to support their friend in a contest?


(Anton) #1

In our contests, we often count likes received to determine the winner.

To raise winning chances, some users asked their friends to register and give likes. As a result, we have some users in activity of whom there are “giving likes” and nothing else.

Is there any means to stop such an activity? Registering new users is, well, very good and some of them will potentially become active readers or even writers with time after receiving mail updates from the forum. However, multiple non-active users who only signed up to give likes is not good for forum.

For example, we could allow to give only 7 likes daily until one receives at least total of 4 likes from different people (not daily, but total starting from registration process).


(⛰️) #2

Do you mean, register for an account on your Discourse instance?

If so, you can possibly change T0/T1 abilities for the duration of the contest.

I would also consider checking to see if T0/T1 users make an immediate dash to the contest’s topic and then cast likes. Those who do would be highly suspect.

EDIT: Also, you may be able to write a query for the database and see which users cast a like within so many minutes or hours after registering.


(Anton) #3

Yep

when I tried to do so, others moaned

It is easy to determine such users. However, the question is how to combat them automatically.

Again, detecting is not an issue. What I’m trying to achieve is the Discourse engine to prevent such activity.

One of the things that can clearly be seen for such users is they give 95% of the likes to the same user, often to the same topic! It might be reasonable to add some functionality and/or corresponding configuration options to Discourse to prevent this.


(⛰️) #4

It depends how far you are willing to go.

This may not be the most eloquent solution, but… I would consider some kind of task script that gets triggered every half hour or 20 minutes (pick your best). It queries the user database for new registrations (eg, either in T0 or T1). If it finds a match based on the query (with likes taken into account and if they are cast on that specific contest’s topic), it auto-suspends the account, or does whatever action you want. Hook into Discourse’s API.


(Matt Palmer) #5

The big question is: what do you want more? Additional long-term active users (that subset of the like-spamming users who hang around afterwards), or a fair competition? Idle users don’t really “cost” much, so that shouldn’t be too concerning; the main issue is whether the “unfairness” aspect damages the forum more than the additional active users.

If you decide you’d prefer to run a fair competition, I think you’ll need to write a small plugin to restrict TL0/TL1 users from giving likes (you need to restrict TL1 from giving likes, because invited users are TL1 by default, and also be careful with the “must have given N likes to be promoted” settings). Such a site setting might be accepted into core, perhaps, but that’s not my bailiwick, so I’d get @codinghorror’s imprimatur before going too wild with a patch to core.

An interesting “middle ground” might be to let everyone “like”, but only actually count likes from certain users – say, those who registered before the contest started, or who were TL2+ (or TL1 and not invited) when they liked, or who have become TL2+ during the contest, or who have otherwise demonstrated some other sort of allegiance to the forum. Whether you announce the criteria, or keep them secret, would depend to some degree on the dynamics of your forum and the competition. I can imagine people would get confused and upset if they saw someone who got “less likes” winning, if you’ve stated at the beginning “the entry with the most likes will win!”, but if likes is a “contributing factor” to the decision of who wins, it’s a lot easier to discount spam-likes discreetly.


(Rafael dos Santos Silva) #6

Wouldn’t be easier to make the contest a poll and put an option in the poll plugin to limit to tl2 only?


(Mittineague) #7

AFAIK the numbers currently exist only for TL2 members in their TL3 requirements.
But I think if you could factor in
num_likes_received_users
and
num_likes_received_days
it would be fairly easy to weed out the Like spammers.

Perhaps the data explorer plugin could be used without there being a need to write a plugin?


(Matt Palmer) #8

It’d be easy enough to use the data explorer to get any sort of report you wanted, but I think if you want to actually block behaviour, you’d need to have a plugin. Then again, I’ve never actually used the data explorer in anger, so perhaps it has more awesome functionality than I’m aware of.


(cpradio) #9

No, it would simply create a report, but if there are only 12 users, it may be manageable without a plugin, if it is 200 users, well then… a plugin may be worth while. It would at least tell you how bad the problem is (if it is of great concern).