Instagram Hashtag Intelligence & Trend Radar

A variant of the Instagram Hashtag Scraper. The scraping core is identical — same internal Instagram API (/api/v1/tags/{tag}/sections/), same session/proxy handling, same post parser. It scrapes posts & reels by hashtag exactly like the base, then adds two layers computed only from the posts it just scraped:

1. 🧠 Intelligence — one summary row per hashtag with aggregate insight.
2. 📈 Trend — a cross-run delta: what is new for a hashtag since the last run.

No value in the added output is estimated, modeled, or hardcoded. Every field is either a raw scraped value or a transparent count / average / median / set-diff of scraped values.

---

Relationship to the base scraper

	Base (instagram-hashtag-scraper)	This variant
Scraping core	internal IG API + impit + proxy ladder	identical (verbatim)
Post output rows	❤️ likes, 💭 comments, caption, hashtags, mentions, owner, media, music …	identical, byte-for-byte, still charged as row_result
Section header rows	free divider row per hashtag	identical
Extra output	—	one free hashtagReport row per hashtag (intelligence + trend)
Purpose	collect posts	collect posts and profile the hashtag over time

Every base input key is kept with the same name, meaning and default. The variant only adds opt-in keys. If you set only the base keys and turn the two feature toggles off, you get base-equivalent output.

---

Input

All base keys are unchanged:

Key	Type	Default	Notes
startUrls	array	["webscraping"]	Hashtags, hashtag URLs, or keywords (with keywordSearch).
sessionid	string (secret)	—	Required. Instagram sessionid cookie.
contentType	posts | reels	posts
keywordSearch	boolean	false	Resolve a keyword to its matching hashtag.
resultsLimit	integer 1–1000	20	Posts collected per hashtag.
proxyConfiguration	object	{ useApifyProxy: false }

Variant-only additive keys:

Key	Type	Default	Notes
emitIntelligence	boolean	true	Emit the per-hashtag intelligence summary row.
trackTrends	boolean	true	Persist seen post IDs and report the cross-run delta.
topN	integer 1–50	10	How many items to keep in each ranked list.

---

Output

Post rows — identical to the base

Each scraped post is pushed as its own dataset row with the base schema (id, type, shortCode, caption, hashtags, mentions, url, commentsCount, likesCount, timestamp, ownerUsername, videoUrl, musicInfo, childPosts, …). These are the billable row_result rows.

hashtagReport row — one per hashtag (free)

Marked with isReport: true, type: "hashtagReport". Fields (all derived from the scraped posts of that hashtag):

Intelligence (emitIntelligence)

• postsAnalyzed, likesKnownFor (coverage, e.g. "18/20" — likes hidden by the author are counted as unknown, never faked to 0)
• totalLikes, avgLikes, medianLikes, totalComments, avgComments, medianComments
• mediaTypeBreakdown — {Image, Video, Sidecar, Reel} counts
• coHashtags — [{tag, count}] other hashtags co-occurring in the captions
• topMentions — [{username, count}]
• audioTrends — [{title, artist, audioId, uses}] from each post's musicInfo
• postingHoursUtc, postingWeekdaysUtc — histograms from each post's timestamp
• topCreators — [{username, posts, totalLikes, totalComments}]
• topPosts — top topN by (likes + comments)

Trend (trackTrends)

• trendIsFirstRun — true when this hashtag has no prior state
• trendNewCount — posts not seen in any previous run
• trendNewSincePrevRunAt — timestamp of the previous run (null on first run)
• trendTotalKnownIds — size of the persisted seen-ID set
• trendEmergingCoHashtags — [{tag, count}] among the NEW posts only
• trendRisingCreators — [{username, newPosts}]
• trendObservedNewPerHour — new posts ÷ hours since previous run (observed in the scraped sample; null on the first run)

Two dataset views are provided: Scraped Posts (base view) and Hashtag Intelligence & Trend.

---

How the trend state works

Seen post IDs are stored per hashtag in a named key-value store (instagram-hashtag-trend-state) that persists across runs — the per-run default store would reset every time. Each run reads the previous ID set, diffs it against the IDs scraped this run to compute what's new, then writes the union back (bounded to the most recent 100k IDs per hashtag). Delete the store to reset a hashtag's history.

Data-provenance guarantee

Every field in the report traces to a scraped value:

• counts/averages/medians → the posts' own likesCount / commentsCount
• coHashtags / topMentions → the posts' hashtags / mentions arrays
• audioTrends → each post's musicInfo object
• posting histograms → each post's timestamp
• trend deltas → set-diff of scraped post ids + date math against the stored run time

Nothing is pulled from a constant table, an assumed default, or a proprietary model.

Billing

Post rows are charged as row_result (pay-per-event), identical to the base. Section headers and the hashtagReport rows are free metadata (not charged). The row_result event must be configured in the Console (Publication → Monetization) for charging to take effect; until then the platform logs an "ignored attempt to charge" no-op.