Hi Taylor;
I’m trying to understand the rationale behind this recommendation.
What should be a relatively simple problem has been flipped on its head and turned into a massively complicated undertaking. For apps that track hundreds/thousands of accounts, it’s not practical to use the Streaming API (limited predicates) to track URL tweets and retweets, you’d only be able to measure 400 at a time. If you processed in batches, you’d have gaps in data/accuracy. Site Streams + Control Streams is overkill and would only include mentions of the URL by users or their followers. The only solution that works reliably is if you sent the aggregate count alongside the URL in the Streaming API response, as is done with the retweet_count.
This is a number that twitter has already processed… why not expose it? Why force every client to redo the work? This imposes a drastic toll (storage, processing, connectivity complexity) on not only the client but on twitter and the network too. Where’s the benefit?
Regards,
N.