A Social Network Analysis Case Study with Gephi

In October 2025, a master's student from a state university in Malang reached out to me. He was working on a thesis about Social Network Analysis and needed fairly specific help: collecting posts from a set of football publisher accounts on Twitter, then mapping how a narrative spread across them.
What made the request both exciting and a little nerve-wracking was that almost every part of it was new to me. I had never run a network analysis project end to end, never used Gephi, and now had to figure out how to get Twitter data at a price that made sense. So the challenge came in layers. It was not simply "go grab the data." It was three things at once: get the data, turn it into something readable and analyzable, and then help the student genuinely understand the process.
I'm writing this as a case-study note, and as a picture of what the journey looks like for anyone who wants to do something similar, even without a deep technical background.
What were we actually mapping?
The biggest temptation in a project like this is to chase the data right away. I held off. Before anything else, I made sure I understood what the thesis was really trying to answer.
Picture a map that contains not roads and cities, but social media accounts. Each account is a point. Every time one account interacts with another, by mentioning, retweeting, or quoting it, we draw a line between the two. Once all the points and lines are drawn at once, a pattern emerges: which account sits at the center of attention, which groups tend to talk to each other, and how a topic travels from one group to another.
That is the heart of social network analysis. Instead of reading posts one by one, you look at the entire conversation as a structure that has a shape and a pattern.
The first wall: where does the data come from?
The most natural move is to pull data straight from Twitter through their official channel. That's exactly where we hit a wall.
First, cost. The official plan needed to pull a meaningful amount of older data sat well above a thesis budget. Second, there were tight limits on how much data you could fetch at once, which made the process slow and easy to break. Third, and most importantly, we needed posts from a specific window in the past, not just the latest ones. Put those three together and the official route felt like a brick wall.
I was stuck for a while. Then I changed my approach: instead of forcing the official route, I looked for another provider that already stored a lot of Twitter data and sold it at a friendlier price.
The way out: a far cheaper data source
That's how I found twitterapi.io, a third-party service that offers access to Twitter data at a far more affordable price and without the harsh limits of the official path. For research on a tight budget, this service genuinely saved the project. We could specify which accounts to pull, what keywords to look for, and from which time range, and the service returned the matching posts.
The technology we used
To keep things clear, here are the tools involved from start to finish:
twitterapi.io as the data source, where we collected Twitter posts at a low cost.
Node.js to build a small program that fetched that data automatically and neatly, instead of copying it by hand.
Gephi, the free, open-source software for drawing and analyzing networks, which turned thousands of rows of data into a visual map.
Collecting the data
Grabbing thousands of posts one at a time made no sense. So we built a small program with Node.js that acted like an assistant: for each publisher account, it automatically requested every post containing the chosen keywords within the time range we set, fetched them page by page until there were none left, and saved them.
One principle I stuck to: save all the raw data as-is first, process it later. That way, if something needs fixing during analysis, we don't have to re-fetch the data from scratch and burn through the budget again.
Turning data into a "map"
Raw data in the form of a pile of posts can't be mapped directly. This is the stage where the real analytical decisions happen.
The logic goes back to the points-and-lines idea. Every time an account mentions, retweets, or quotes another account in a post, there's a relationship we can draw as a line. From all the collected posts, we built two simple lists: one with every account involved, and another with the connections between accounts and how often each connection happened. The more often two accounts interact, the thicker the line that will connect them later.
We saved both lists in a file format Gephi can read.
Learning Gephi from scratch
This was the part I was most nervous about, and it turned out to be far friendlier than expected. Gephi works by clicking and adjusting rather than writing code, so it's easy to follow even on your first try. The flow looks roughly like this:
Load the data. The two lists (the accounts and the connections) are imported into Gephi. The first result is still a messy pile of points.
Tidy up the layout. Gephi can arrange the points automatically. Connected accounts get pulled close together while unconnected ones drift apart. From here the network structure starts to show.
Compute the important patterns. With a few clicks, Gephi can detect the groups (communities) that form naturally and flag which accounts are most influential in passing information along.
Add color and size. Each group gets a different color, and the most influential accounts are made larger. At this point the once-confusing picture turns into a map that tells a story on its own.
Export the result. The final view can be exported as an image to drop into the thesis.

The hardest part isn't the data, it's the meaning
At this point, a lot of people assume the work is done. But that colorful picture means nothing until someone reads it. This is exactly where the biggest challenge shows up, and it's what separates "helping grab data" from "helping with research."
I walked the student through reading his map. The largest accounts, the ones the most information flows through, are bridges, accounts that play a crucial role in carrying a message from one group to another. The groups that form show communities that interact more densely within themselves, which can be read as clusters with a particular angle or reporting style on the topic being studied.
From here, data turns into a narrative. It's no longer just "there are a few groups," but a sentence like "the conversation concentrates within a specific set of publishers and spreads outward through a handful of connector accounts." That's a sentence you can defend in front of a committee.
Just as important, I didn't want the student to simply receive a finished result. So I guided him through understanding every stage, so that if his advisor asked for an adjustment, he could explain it and do it himself.
What I took away
This project was fun precisely because almost all of it was new. I relearned that a dead end on one path, like an official route that's too expensive, is often just a sign you haven't found the right alternative yet. I was also reminded that the value of an analysis doesn't live in the tool, but in the ability to translate technical results into a story other people can understand.
Personally, the most satisfying part wasn't when the network map came together. It was when the student finally understood the whole flow and could explain it with confidence.
If you're facing something similar, whether it's data collection, analysis, or building tools to support research or business, I'm happy to talk it through. You can find more of what I work on at harislabs.id.
