How I Built a Threads Analytics Tool with 10,000 Users In 3 days
Since Meta launched Threads last year, this new app has blown up among Taiwanese users for its simplicity and content diversity. For months, Threads had been the most downloaded soicla media app in Taiwan.
Yet, as a Taiwanese developer and former social media curator, I noticed that there wasn’t an analytics tool for Threads, unlike the numerous services available for Facebook and Instagram.
I decided to develop an analytics tool capable of assessing the activity level of Threads accounts. As a result, the tool I crafted successfully analyzed over 3,200 accounts and attracted more than 100,000 views within just a week of its launch.
The experience of handling substantial and unpredictable traffic volumes was highly educational, and I gained invaluable insights from this side project, and I would like share what I’ve learned in this article.
There are 3 major topics that I would like to share with you:
- The methods I use to designed and improved the infrastructure and workflow to manage a large volume of time-intensive task requests
- The strategies I implemented to make the final statistical report more engaging and user-friendly, thereby encouraging users to share it more frequently
- The challenges and difficulties I faced during the developement and production
Disclaimer
The technology mentioned below and the analytics tool was developed for educational and research purposes only. Using or distributing the code might violate the terms of service of Meta and its associated services.
Any actions or activities related to the material contained within this atricle are solely the reader’s responsibility. I do not support, encourage or condone any unethical or illegal activities.
Threadseeker: The First Threads Analytics Tool
Firstly, I’m excited to introduce the final product of my work: Threadseeker.
With just a username, you can easily request an analytics report of the Threads account, which will be delivered to you within a few days:
The screenshot below offers a glimpse into an actual report, showcasing key metrics such as daily posting frequency and the total number of interactions across the most recent 40 posts:
It might seem odd that the report isn’t available immediately after it’s requested. You might also be curious about the workflow development process. I’ll dive into the technical specifics in the content below.
Workflow & Infrastructure: A Deep Dive into My Improvements
I would like to break down the workflow and the system design behind Threadseeker.
Since the distinctiveness of the analytics task, these two aspects are crucial for ensuring the service’s availability and stability when retrieving data from Threads platform.
Tech Stack & Infrasturcture
Threadseeker is powered by Nuxt3 for the frontend, utilizes Redis for response caching, Supabase for data storage, and leverages Google Cloud Functions for data retrieval from Threads.
Essentially, Nuxt3 is tasked solely with handling search requests and displaying reports, while Cloud Functions take care of everything else, including retrieving data from Threads and performing statistical analysis.
The Nuxt web interface and the data retrieval program are both deployed in a serverless environment, which has significantly reduced the costs for this project. The monthly expenses amount to approximately $7 USD.
Additionally, the traffic stemming from Cloud Functions and specific API requests in Nuxt is strategically proxied through IP rotation to circumvent rate-limiting issues.
Workflow: Task Scheduling Approach
Threadseeker employs task scheduling to manage analytics requests efficiently.
Upon receiving a search request, the backend promptly queues a task into the database. Subsequently, the data retrieval program regularly processes the tasks in the queue.
The strategy guarantees consistent performance, even with a high volume of requests, while maintaining the integrity of the Threads APIs through rate-limiting safeguards.
However, this approach was adopted after I had already enhanced the workflow.
I actually didn’t come up with the method first. I would explain my intentional journey in following paragraph.
Workflow Imrpovement
At the beginning, Threadseeker used a just-in-time approach, initiating the data retrieval process immediately upon request receipt.
This method might work for individual use, allowing users to receive their reports without any delay.
However, the growth exceeded my expectations. Within just three days of launching, Threadseeker has catered to over 2,000 real-time users and has processed an average of 100+ analytics requests per hour.
This presented a significant challenge in managing such substantial and unpredictable traffic. Threadseeker’s has faced multiple outages — since the data retrieval programs hit a snag when they exceeded the rate limits set by the Threads API.
The just-in-time method fell short in this context, hindered by our dependence on the rate-limited API for fetching data.
I quickly identified a bottleneck in the data retrieval process, underscoring the need to protect and regulate the task processing speed.
So I devised a task scheduling approach, getting inspiration from the account information download requests on Meta.
The enhancement has significantly improved the success rate of analytics tasks. For those who require frequent data retrieval, it’s advantageous to queue the tasks and process them on a regular schedule rather than immediately.
Crafting a Compelling Report That Users Can’t Wait to Share
From my perspective, what really sets Threadseeker apart is its intuitive report design. I have put lots of effort into demystifying statistical results for the users, many of whom may not be well-versed in statistics ( So am I )
My primary objective is to encourage users to share their results on social media to boost the exposure of Threadseeker.
Therefore, it’s important to carefully select the report’s content and express it in simple language, ensuring that users can grasp and engage with the information effortlessly.
So I’ve developed a scoring system that allows users to understand their activity level on Threads. Like to pseudo-code below:
// The standard aren't accurate
function determineActivityLevel(postDensity: number): string {
if (isNaN(postDensity)) return 'C';
if (postDensity < 0.5) return 'C'; // Below PR 35
if (postDensity < 0.7) return 'B'; // PR 35 ~ 45
if (postDensity < 1) return 'B+'; // PR 45 ~ 50
if (postDensity < 1.2) return 'A'; // PR 50 ~ 75
if (postDensity < 3.6) return 'A+'; // PR 75 ~ 85
if (postDensity < 5) return 'A++'; // PR 85 ~ 90
if (postDensity < 10) return 'S'; // Above PR 91 ~ 95
return 'SSS';
}The users can view their scores directly on the report, which are calculated using key metrics such as daily posting frequency and interaction rate of their content.
Users may not fully appreciate their activity level just by looking at the number of daily posts. Yet, by translating this into a grading system with different levels, they can see how engaged they are, which often spurs a desire to share their status online as a badge of their activity.
The reposts and discussions about Threadseeker on Threads have proved my thought. The majority of users are more interested in their activity levels rather than the other statistical figures.
The Challenges in Development
API Rate Limiting
The most challenging part of developing Threadseeker is to fetch the account ‘s data while not exceeding the rate-limit of the APIs.
To address this, I implemented a task scheduling system to modulate request frequency and utilized proxies for IP rotation to evenly distribute the traffic.
Make Users Feel Safe
Another issue that arose was user concerns regarding Google OAuth. While some users feared that OAuth might be a scam to hack their accounts, I needed to clarify that its use in my project is solely for API protection.
But indeed, users’ concerns regarding Google’s OAuth strategy are justified, especially considering that most analytics tools do not require a login.
As a developer, it’s really crucial to adopt the perspective of a user when crafting the user flow for your project, ensuring they can feel that the product is both user-friendly and secure even without knowing the technical details.
In the end, I solved this issue by setting a FAQ page and a promt below the login button, explaing the purpose of OAuth and how the data from OAuth will be stored.
Conclusion
For me, developing the first Threads analytics tool has been quite a journey. It has offered me a unique perspective on Threads as well as other social media platforms.
When you make your idea into practice, gaining lots of users and statistical insight from the results. You will start to see those social media platforms in a different light.
You can begin to envision the wealth of valuable insights that could be gleaned as a platform from a more comprehensive dataset and user interactions.
This is particularly true given that, even as a third-party user, which is me, has limited access to a certain level of information through my data fetching services. I still get some insights from the data collected by Threadseeker.
I hope this article proves to be helpful to you, and any comments and suggestions will be appreciated.
Special Thanks
Last but not least, I would like to express my thanks to Chi Wei Lin CW (林啟維) , the founder of portaly.cc, and Max Yi-Hsun Chou 周奕勳, my upperclassman in National Taiwan University, and Joey Lu, my former employer, who has inspried me for the numerous ideas that gains lots of traffics on social media.
Without their invaluable and expert advice, Threadseeker might not have achieved its popularity and could still have encountered numerous technical challenges.
