Discussion in 'News & Announcements' started by ChrisTurk, Nov 5, 2017.

  1. ChrisTurk

    ChrisTurk Administrator

    HIT API Beta
    This is only for worker.mturk.com! You must also be logged into TurkerView for it to work.


    The idea is to give folks more digestible data from the website. Envisioned use cases:
    • Shared Requester Accounts - Some HITs might blow chunks, some might be great, this will help differentiate
    • Variety Requesters - Some Requesters (Rekogs come to mind) have a variety of HITs and each one has its own unique pay rate. While a general profile overview is helpful, if you look at these kinds of Reqs on TO they end up being blood red because, well, everyone wants to review a crap HIT. This helps solve that problem, again w/o removing the full data profile completely.
    • Declining pay scales - the lookup key is built with the base reward amount in mind, so if a Requester lowers (or raises) the pay on their HITs the API wont feed you inaccurate data. I think this is a fantastic way of "fixing" the stale data problem TO suffers from (and TV will suffer from eventually) without outright discarding historical data in the Requester's aggregate.

    Your script should update automatically, but if you prefer to get the changes right away you can do this:

    Bugs, suggestions, improvements. HIT me with them please so I can improve this from its current state.

    One big problem the site has right now is that aggregating data between Requester & individual HITs can cause pretty large discrepencies on small value HITs (penny HITs). Example:
    Obviously all 3 reviews are for the same HIT, but the requester aggregate is an average of $11.50/hr (because it calcs the average reported hourly) whereas the HIT aggregate takes the total completion time and calculates the average pay for that. The math:

    R_AGG = (12.00 + 18.00 + 4.50) / 3 = $11.50/hr
    H_AGG = (3600 / ( (3+2+8)/3 )) * 0.01 = $9.00/hr [note: even more inaccurate because the result of the completion time average is rounded to a full integer value (in this case 4 vs 4.33~) which exacerbates the issue]

    I am not a math wiz, if anyone has ideas to bring these values closer to each other while fitting within the constrains of the DB toss 'em at me. I only just noticed this problem about 10 minutes ago and its 1AM so I have given it zero thought, please be gentle if the answer is stupid obvious HAHA (jk I don't care).
    • Today I Learned Today I Learned x 2
    • Love Love x 1
    Last edited: Nov 5, 2017