The problem

Manual data collection

Before social tracking, measuring an event's social footprint was manual. The SWSH team would collect creator handles, open each profile, and copy engagement numbers into a spreadsheet by hand.

The process was slow and error prone. It didn't scale past a handful of creators, so campaign results were screenshots rather than a live, aggregated dashboard.

The prototype

Started on Modash platform

The first version of social tracking leaned on Modash’s SaaS platform to track and manage creator content and data.

The goal was to validate the idea before committing engineering effort to it: Given a list of creator handles content and important metrics could be reliably captured, attributed to a campaign, and rolled up into insights brand would value. This let SWSH prove the product was useful without first building a full ingestion pipeline

The switch

From prototype to product

Engagement on event content moves fastest in the first hours and days. Manually re-pulling data wasn't sustainable across dozens of creators per campaign, run across several campaigns at once. SWSH needed:

• Programmatic ingestion, instead of manual pulls
• A refresh schedule that checks recent posts
• Structured, typed data that could be stored and aggregated

That combination of needs is what moved SWSH onto the Modash API.

The product

What SWSH‘s Social Tracking product does today

A customer creates a campaign, which comprises of an event, event details, and sources to track. They can paste a full list of creator handles at once, attach labels, apply content filters, and preview the results before saving.

From there, SWSH continuously pulls in matching posts and keeps their engagement current in the background. The customer sees five summary cards, for total likes, total comments, total views, total impressions, and content items, plus a sortable table of every post with thumbnail, platform, post type, creator, caption, date, and per-post metrics. Posts can be filtered, enabled or disabled, added manually, or copied between campaigns. Customers can also view posts over time and export the data.

Before vs After

The difference: staying fresh

A customer creates a campaign, which comprises of an event, event details, and sources to track. They can paste a full list of creator handles at once, attach labels, apply content filters, and preview the results before saving.

[data-block-testimonial]

From there, SWSH continuously pulls in matching posts and keeps their engagement current in the background. The customer sees five summary cards, for total likes, total comments, total views, total impressions, and content items, plus a sortable table of every post with thumbnail, platform, post type, creator, caption, date, and per-post metrics. Posts can be filtered, enabled or disabled, added manually, or copied between campaigns. Customers can also view posts over time and export the data.

[data-block-before-after]

The engine

The API endpoints behind the feature

All social data flows through Modash's Raw API endpoints.

[data-block-api]

Built on top

Built on top of the creator data

Runtime schema validation

Every Modash response is validated against typed schemas pulled from Modash's OpenAPI spec, so a malformed or unexpected payload fails loudly instead of corrupting a campaign.

Quirk patches and normalization

Real-world variance in the raw data is handled and normalized into single cross-platform content record that includes likes, comments, views, shares, caption, posted-at, tags, mentions, media, as well as trimmed platform-specific detail. This is done to ensure that data from different social platforms end up looking the same to the rest of the app.

Aggregation and segmentation

Campaign totals are summed across posts. Content is segmented by creator, by hashtag or mention, and by free-text labels that carry through into CSV exports.

Estimated impressions

Where a platform doesn't return a real number, SWSH computes an estimate from engagement and followers, falling back to real view counts when they're available.

The architecture

Keeping it up-to-date

A scheduler runs a periodic sweep and decides what's due for a refresh, applying two independent schedules, each with its own queue and processor.

On a freshness-based schedule, the source-refresh pipeline fetches new content for each given source, a creator feed, or hashtag. On the age-based schedule, the content-refresh pipeline re-checks engagement on posts already being tracked, refreshing recent posts most often and tapering off as they age, batching many into a single pass where possible to conserve API budget.

Content is copied into durable object storage so they survive after the original links expire. Normalized posts live in a data store, where campaign totals are aggregated on read and segmented by creator and label, then served to the dashboard and CSV export. Modash API is the single external data source feeding both pipelines.