DdmrDdmr
Legendary
Offline
Activity: 2310
Merit: 10759
There are lies, damned lies and statistics. MTwain
|
Great post. All drilled-down stats are a smashing way of exploring the data and trying to uncover flaws or the magic of the system.
I wondered myself how much sMerit was being given in a circular manner, that is subject A gives it to subject B and subject B gives it to subject A (not necessarily in the same order of magnitude). This is not necessarily a wrong thing to do, since I may be merited by someone, checkout his posts, and decide to give him some sMerit for one of his good posts. It could also be an indicator to farmed accounts meriting each other or pacts between users.
Regardless, my focus was just on trying to see how often it happens, and not going in to the detail of whether it is justified or not.
Using the most recently updated Raw Data source that I’ve found (timeframe 24/01/2018 through to 09/03/2018) , I decided to study that period as a whole, without baring other variables than the Meriter, the Merited, and the sMerit assigned within that period (i.e. no breakdown by dates/times nor ranks – by the way I cannot see the Rank in the raw data).
The initial dataset data for the given period shows: Transferred sMerit in period: 97.171 Number of sMerit Transaction: 41.700
What I created was a table with the following information: User_from: Meriter User_to: Merited NumTimesGiven: Number of sMerit Transactions from Meriter to Merited SumMeritGiven: sMerit Transferred from Meriter to Merited NumTimesReceived: Number of sMerit Transactions from Merited to Meriter SumMeritReceived: sMerit Transferred from Merited to Meriter Percent_given_over_received: Percentage of Given sMetir over received sMerit between Meriter and Merited
The above table is the starting point, holding all the pairs of sMerit transferred between Meriter and Merited, and vice-versa. The problem is that each user is included in the table twice potentially (as a Meriter and as a Merited subject). I therefore created a derived table that avoided the above issue, making each person figure only once in the table for a given Meriter/Merited couple.
In global, of the 91.171 sMerits given, 87.183 where inventoried as “given” and 9.988 as “received back”. That should not be taken verbatim since the process of keeping only one record for each pair of Meriter/Merited users is arbitrary (i.e. A giving sMerit to B is a record, but I could also have chosen B giving to A).
Where I really wanted to get to was finding pairs that had a similar ratio of sMerit given than received.
First I deleted all records that sent sMerit from subject A to B, but did not receive sMerit from subject B to A. The net amount of records now goes down to 2.976, with 22.880 sMerits involved (23, 55%).
Examples:
user_from user_to NumTimesGiven sumMeritGiven numTimesReceived sumMeritReceived Percent_given_over_received 729995 1115343 2 77 1 5 1540,00% 822485 990983 5 55 2 55 100,00% 511933 822485 2 55 2 14 392,86% 181084 213773 2 50 1 50 100,00% 112286 135065 1 50 2 50 100,00% 944905 1076869 4 50 3 50 100,00% 913200 914767 1 50 1 50 100,00% 316540 377879 1 50 1 41 121,95% 1001911 1064065 2 50 1 41 121,95% 988901 1033117 9 50 8 37 135,14% 1005975 1093441 2 50 3 30 166,67% 842041 1123153 4 50 2 28 178,57% 221867 298905 1 50 1 26 192,31% 336733 373994 1 50 5 23 217,39% 756570 1035345 1 50 1 18 277,78% 831989 1350445 2 50 1 11 454,55% 389331 935622 1 50 1 10 500,00% 915311 944905 3 50 2 10 500,00%
If we narrow down the query to those records where Percent_given_over_received is within the range of 80..120% (that is, sMerit given from A to B is roughly what B receives from A), the number of records (cases) goes down from 2.976 to 1.294, with cases such as:
user_from user_to NumTimesGiven sumMeritGiven numTimesReceived sumMeritReceived Percent_given_over_received 822485 990983 5 55 2 55 100,00% 181084 213773 2 50 1 50 100,00% 112286 135065 1 50 2 50 100,00% 944905 1076869 4 50 3 50 100,00% 913200 914767 1 50 1 50 100,00% 95437 860708 3 39 2 38 102,63% 1018920 1035345 1 36 1 31 116,13% 979216 982124 1 34 2 38 89,47% 1036967 1122909 2 34 4 29 117,24% 101872 976210 6 33 17 30 110,00% 771836 882756 3 31 4 31 100,00% 964133 1334470 4 29 6 30 96,67% 98986 153656 7 28 2 30 93,33% 1052553 1113026 1 27 1 26 103,85% 976210 1764044 22 24 5 20 120,00% 934304 939859 2 20 3 20 100,00% 81995 662293 1 20 20 20 100,00% 202760 598528 1 20 1 20 100,00%
Being the aggregate summarized as follows:
sMerit NumCases 55 1 50 4 39 1 36 1 34 2 33 1 31 1 29 1 28 1 27 1 24 1 20 6 19 1 17 1 16 1 15 2 14 1 13 1 12 2 11 5 10 21 9 4 8 13 7 13 6 24 5 44 4 30 3 30 2 162 1 918 Grand Total 1.294
So in summary (working on this last table where Percent_given_over_received is within the range of 80..120%, since I was aiming studying a similar sMerit transfer/receive amount -> these I call paired sMerits):
- The vast majority of paired circular sMerits are relative to 1 or 2 sMerits: 83,46% - High paired circular sMerit transfer/receive Txs occur in 4,33% of circular assigned paired sMerits (10 sMerits or above).
- From a global perspective, 23,55% of sMerit asigned seems to be involved in circular sMerit asignment.
A lot more can be done with more detailed raw data and the precious element of time which I lack..
|