Instagram Viral Content Intelligence

Find genuinely high-performing Instagram posts by normalizing creator size, historical performance, engagement velocity, comments, and post age — with deterministic, explainable viral scoring.

The core principle is simple: most likes is not the same as most viral. A post from an 18k-follower creator performing 8× above that creator's own baseline can be a much stronger signal than a 2M-follower account producing its usual numbers.

Unofficial tool. This Actor is an independent third-party product and is not affiliated with, endorsed by, sponsored by, or operated by Instagram or Meta Platforms, Inc. "Instagram" and "Meta" are trademarks of their respective owners. The Actor works with public data obtained through third-party Apify Store Actors.

---

What this Actor does

Instagram Viral Content Intelligence helps creators, marketers, agencies, analysts, and developers identify content that is genuinely outperforming expectations — not merely content with the largest raw engagement totals.

It can:

• Analyse one Instagram account
• Compare 2–10 competitor accounts
• Normalize engagement by follower count
• Compare a post against the creator's own historical baseline
• Measure engagement velocity relative to account size and post age
• Measure comment strength
• Score view amplification when a valid view metric is available
• Produce a deterministic viral score from 0–100
• Classify posts as NORMAL, ABOVE_AVERAGE, HIGH_PERFORMING, VIRAL, or EXTREMELY_VIRAL
• Report score confidence separately from viral score
• Explain each score with human-readable evidence
• Handle collaboration posts without losing the requested-account context
• Return structured warnings when data is missing or a provider partially fails

No language model participates in V1 scoring. Given the same normalized source data, scoring configuration, and evaluation time, the scoring calculation is deterministic and reproducible. Live Instagram metrics can change between runs, so identical user input does not guarantee identical source data.

---

Why this is different from "most likes"

Raw likes heavily favor large accounts. This Actor instead evaluates a post relative to its context:

• How large is the creator's audience?
• How does the post compare with that creator's normal performance?
• How quickly is engagement accumulating relative to follower count?
• How strong is the comment signal?
• Does a video have meaningful view amplification?
• Is the baseline reliable?
• Are any expected metrics missing?

That allows the Actor to surface smaller-account posts that are genuinely outperforming expectations while avoiding the assumption that the largest account is automatically the most viral.

---

Current capabilities

• Single-account viral-content analysis
• Competitor comparison across 2–10 accounts
• Creator-size-normalized engagement analysis
• Historical creator-baseline comparison
• Engagement-velocity analysis
• Comment-strength analysis
• Deterministic 0–100 viral scoring
• Score confidence and explainable evidence
• Collaboration-aware analysis
• Structured warnings and partial-result handling
• Baseline-history coverage reporting
• Primary/fallback provider handling with confidence penalties when fallback data is used

---

Quick start

Analyse one Instagram account

{
  "mode": "account",
  "accounts": ["nasa"],
  "lookbackDays": 30,
  "postsPerAccount": 30,
  "topResults": 10
}

Compare competitors

{
  "mode": "competitors",
  "accounts": ["competitor1", "competitor2", "competitor3"],
  "lookbackDays": 30,
  "postsPerAccount": 30,
  "topResults": 20
}

Run the Actor and open the Dataset to see ranked posts. Each returned item includes the viral score, classification, score confidence, normalized metrics, creator-baseline comparison, collaboration context where applicable, and human-readable evidence explaining the score.

---

Input

account mode

Analyse exactly one account:

{
  "mode": "account",
  "accounts": ["your_account"],
  "lookbackDays": 30,
  "postsPerAccount": 50,
  "topResults": 20
}

competitors mode

Compare 2–10 accounts:

{
  "mode": "competitors",
  "accounts": [
    "competitor1",
    "@competitor2",
    "https://instagram.com/competitor3/"
  ],
  "lookbackDays": 30,
  "postsPerAccount": 50,
  "topResults": 20
}

Field	Default	Maximum	Notes
mode	—	—	"account" or "competitors"
accounts	—	10	Usernames, @handles, or Instagram profile URLs
lookbackDays	30	365	Analysis window in days
postsPerAccount	50	200	Number of recent posts considered for ranking; collection may request additional history for baseline quality
topResults	20	100	Maximum ranked results returned

Accounts are normalized (@NASA, https://instagram.com/NASA/ → nasa), deduplicated, and validated per mode:

• account requires exactly one unique account
• competitors requires 2–10 unique accounts

Values above supported maximums are clamped and the clamp is reported. Invalid input produces a structured failure rather than a raw stack trace.

---

Output

Ranked records are written to the default Dataset. The complete structured result is also written to the key-value store under OUTPUT.

OUTPUT has two schema-valid variants:

• a completed analysis with run.status of SUCCEEDED or PARTIAL
• a structured failure with run.status of FAILED plus an error object

Structured failures cover invalid input, runtime failures, and monetization errors such as invalid Pay-Per-Event configuration, insufficient maximum run charge, or an incomplete billing operation.

The two variants are disjoint on run.status.

Example completed output

{
  "run": {
    "status": "SUCCEEDED",
    "version": "1.0.1",
    "scoringWeightsCalibrated": false,
    "calibrationVersion": "V1_LIVE_ROUND_1"
  },
  "query": {
    "mode": "competitors",
    "accounts": ["nasa", "natgeo"],
    "lookbackDays": 30,
    "postsPerAccount": 50,
    "baselineLookbackDays": 90,
    "collectionLookbackDays": 90,
    "collectionResultsPerAccount": 50
  },
  "summary": {
    "accountsRequested": 2,
    "accountsAnalyzed": 1,
    "accountsWithNoRecentPosts": 1,
    "postsCollected": 6,
    "postsAfterDeduplication": 5,
    "baselinePoolSize": 3,
    "postsScored": 3,
    "postsReturned": 3,
    "collaborationPosts": 2,
    "partialFailures": 0
  },
  "baselineCoverage": [
    {
      "analysisAccount": "nasa",
      "requestedHorizonDays": 90,
      "actualCoverageDays": 90,
      "recordsCollected": 6,
      "collectionLimitReached": false,
      "fullHorizonCovered": true
    }
  ],
  "viralPosts": [
    {
      "rank": 2,
      "viralScore": 15.3,
      "classification": "NORMAL",
      "scoreConfidence": 0.75,
      "analysisAccount": "nasa",
      "analysisAccountFollowers": 104427770,
      "contentOwner": {
        "username": "nasajohnson"
      },
      "isCollaboration": true,
      "metrics": {
        "likes": 87226,
        "comments": 725,
        "views": 488033,
        "plays": 3169526,
        "performanceMultiplier": 1.21,
        "engagementRatePercentPerHour": 0.0005
      },
      "scoreBreakdown": {
        "creatorOutperformance": 12.4,
        "commentStrength": 9.1
      },
      "effectiveWeights": {
        "creatorOutperformance": 33.75,
        "viewAmplification": 0
      },
      "baseline": {
        "baselineType": "ORGANIC_CREATOR_WIDE",
        "engagementBasis": "LIKES_AND_COMMENTS",
        "baselineSampleSize": 2,
        "baselineReliable": false
      },
      "evidence": [
        "Collaboration post: published to @nasa's feed but authored by @nasajohnson; scored as performance on @nasa",
        "1.21x this account's median engagement across only 2 comparable post(s) - low-confidence baseline"
      ]
    }
  ],
  "warnings": [
    {
      "code": "NO_RECENT_POSTS",
      "username": "natgeo",
      "message": "..."
    }
  ]
}

run.version and .actor/actor.json's version are deliberately independent:

• run.version is the application release version, kept in sync with package.json, and is reported for output provenance
• .actor/actor.json uses Apify's Actor build-version line and may use a shorter MAJOR.MINOR form

They are not expected to match.

---

How the viral score works

The weighted-engagement foundation is:

weightedEngagement = likes + comments × 3

The score uses six configured signals. Each signal is normalized to a bounded 0–1 range so extreme long-tail values cannot dominate the score.

Signal	Weight	Basis
Engagement vs followers	25	weightedEngagement / followers
Creator outperformance	27	Current post vs creator baseline median
View amplification	15	views / followers for applicable video content
Comment strength	17	comments / (likes + comments)
Engagement velocity	16	Follower-normalized weighted engagement per hour
Shares	0	No usable share metric is currently supplied by the V1 provider path

Velocity is follower-normalized. This avoids systematically favoring large accounts simply because they accumulate more absolute engagement per hour.

The final score is:

viralScore = Σ(normalizedSignal × effectiveWeight)

Classification bands are:

Score	Classification
90–100	EXTREMELY_VIRAL
75–89.9	VIRAL
60–74.9	HIGH_PERFORMING
50–59.9	ABOVE_AVERAGE
Below 50	NORMAL

The output reports the effective weights actually used for each post.

---

Missing-signal handling

V1 deliberately distinguishes between a signal that is structurally not applicable and a signal that should exist but is missing.

Structurally not applicable

Example: an image or carousel has no meaningful video-view metric.

In this case, the unavailable signal's weight may be redistributed across available signals because the absence is expected for that content type.

Expected but missing

Example: a Reel should have a valid view count, but the provider returns no usable view metric.

In this case, the view-amplification weight goes unearned rather than being redistributed. Confidence is also reduced. Play count is never silently substituted for view count.

This prevents a data gap from artificially inflating the other signals.

---

Analysis window vs baseline horizon

The Actor separates the user's ranking window from the historical baseline horizon.

Posts are collected across:

max(lookbackDays, baselineLookbackDays)

The default baseline horizon is 90 days.

• Posts inside lookbackDays are score candidates and are the only posts that can appear in the ranked output
• Older posts inside the baseline horizon can contribute to the creator baseline only

This helps low-cadence creators build a more useful historical baseline without polluting the user's requested ranking window.

Both horizons are reported in the output.

---

Collection limit vs ranking limit

postsPerAccount controls how many recent posts the user wants considered for ranking, but the Actor may request additional historical records to establish a useful baseline.

The collection target per account is:

max(postsPerAccount, preferredBaselineSamples + baselineCollectionHeadroom)

In V1, that baseline floor is designed so that very small ranking requests do not automatically make reliable baseline comparison impossible.

The actual collection target is reported as:

query.collectionResultsPerAccount

topResults affects how many ranked results are returned. It does not reduce the underlying collection required for the analysis.

---

Engagement-basis comparability

A post's available metrics determine its engagement basis:

• LIKES_AND_COMMENTS
• COMMENTS_ONLY
• LIKES_ONLY

Baseline comparison is always performed using a comparable engagement basis. Baseline members that cannot provide the required basis are excluded and counted rather than mixing incompatible quantities.

When engagement is degraded to a partial basis, signals whose saturation points were defined for complete engagement can be disabled rather than producing misleading scores.

---

Creator baseline

Creator outperformance uses a median, not a mean, so a single past viral post cannot distort the baseline.

The baseline:

• always excludes the target post itself
• excludes pinned posts
• excludes carousel child records
• excludes future-dated posts from the baseline
• prefers a content-type-specific baseline when enough comparable samples exist
• falls back to a creator-wide baseline when needed
• distinguishes sponsored from organic behavior
• reports exclusions and reliability metadata

A minimum of 5 comparable samples is considered reliable. 10+ is preferred.

---

What score confidence means

scoreConfidence measures data completeness and score reliability. It is not the probability that a post is viral.

Confidence starts below 1.0 and is reduced for conditions such as:

• missing followers
• hidden or unavailable likes
• a video missing its expected view metric
• a thin or absent baseline
• organic fallback for sponsored content
• future timestamps
• fallback-provider data

Every deduction is itemized in confidencePenalties.

Confidence is per post. A failure on another account in the same run does not reduce the confidence of an otherwise healthy post.

LIKES_HIDDEN and LIKES_UNAVAILABLE are tracked separately.

A high score with medium confidence can still be useful; the Actor prefers transparent uncertainty over false precision.

---

Collaboration posts

Collaboration posts can appear in a requested account's feed while being authored by another account.

The Actor preserves both contexts:

• analysisAccount = the requested account whose feed/performance is being evaluated
• contentOwner = the actual author
• isCollaboration = collaboration indicator

The post is scored using the requested account's follower count and historical baseline while preserving true ownership in the output.

If the same collaboration appears in two requested competitor feeds, it is intentionally retained once per requested analysis-account context because those represent two different analytical questions.

Deduplication is scoped to the analysis account plus post identity, so duplicate provider records for the same account still collapse.

---

Partial results and warnings

One failed account does not necessarily fail the whole analysis. The Actor returns whatever can be analysed and reports structured warnings.

Possible warning codes include:

• PROFILE_FETCH_FAILED
• PROFILE_PRIVATE
• PROFILE_NOT_FOUND
• POST_COLLECTION_FAILED
• NO_RECENT_POSTS
• MISSING_FOLLOWERS
• INSUFFICIENT_BASELINE
• LIKES_HIDDEN
• LIKES_UNAVAILABLE
• VIEW_METRIC_MISSING
• DUPLICATE_POST
• PINNED_POST_EXCLUDED
• POST_OUTSIDE_LOOKBACK
• INVALID_TIMESTAMP
• FUTURE_TIMESTAMP
• COLLABORATOR_POST
• UNATTRIBUTED_POST
• PROVIDER_FALLBACK_USED
• NO_POSTS_COLLECTED
• POST_NOT_SCOREABLE
• BASELINE_HISTORY_TRUNCATED

run.status becomes PARTIAL only for genuine degradation, such as provider failure or fallback use.

A valid public account that simply has no rankable posts inside the user's analysis window can still produce a complete SUCCEEDED result with a NO_RECENT_POSTS warning.

---

Pricing

This Actor uses Apify's Pay Per Event pricing model.

The primary billing unit is a source post. A source post is a unique Instagram analysis-context post processed by the Actor, including posts used only to build the creator's historical performance baseline.

The current price is always shown on the Actor's Apify Store page.

What affects the number of billable source posts?

The main factors are:

• number of Instagram accounts analysed
• postsPerAccount
• baseline history required for reliable comparison

topResults controls how many ranked posts are returned. It does not reduce the amount of source data required for the analysis, so it is not a billing control.

For example, requesting one ranked result may still require multiple historical posts to establish the creator baseline.

An Actor-start event is also charged automatically by Apify.

Platform usage is included in the Actor's Pay Per Event pricing; users are not charged a separate platform-usage fee by this Actor.

Before paid collection starts, the Actor verifies that the run's maximum charge can cover the requested analysis. If the configured maximum is too low, the run fails before starting paid Instagram data collection.

See the current Apify Store pricing panel for authoritative prices.

---

Known limitations

These are properties of the current V1 providers and scoring model and should be considered when interpreting results.

• Scoring weights are provisional, not statistically trained. The current weights and saturation values were established through engineering design and live calibration rounds, but they have not been fitted to a labelled ground-truth dataset of viral outcomes. scoringWeightsCalibrated therefore remains false.
• Shares are unavailable. Live provider testing did not produce a usable share-count field, so the V1 share weight remains 0.
• Views and plays are different metrics and are never merged. Only the valid view metric drives view amplification. If a video has plays but no valid view count, view amplification is unavailable, its weight goes unearned, and confidence is reduced.
• Public/logged-out Instagram data can differ from logged-in values. Engagement counts can also change naturally between scrapes.
• Collaboration posts require analysis context. The same post can legitimately have different scores when evaluated against different requested accounts because follower counts and historical baselines differ.
• Hidden or missing likes degrade scoring. When key engagement volume is unavailable, affected signals can be disabled or go unearned rather than being estimated.
• Baseline history can be truncated. The 90-day baseline horizon is a requested ceiling, not a guarantee that the full period was collected. Coverage is reported explicitly in baselineCoverage.
• Invalid timestamps are excluded from ranking. Future-dated posts are retained for diagnostics but cannot gain a velocity advantage.
• A wider baseline horizon can require more source posts than the ranking window alone. This is necessary for creator-relative analysis.
• No comment intelligence, LLM interpretation, niche mode, hashtag mode, or original-content recommendation engine is included in V1. These are outside the current release.

---

Technical architecture

accounts ──> profile scraper ──> follower metadata
                                      │
         ──> post scraper ────────────┤
             (detailedData)           │
                                      ▼
                           canonical normalization
                                      │
                           join followers
                                      │
                                  dedupe
                                      │
                                date filter
                                      │
                     creator baseline (self-excluded)
                                      │
                     deterministic viral score 0–100
                                      │
                           rank ──> Dataset + OUTPUT

Source layout:

src/
  config/         weights, saturation points, confidence penalties, limits, Actor IDs
  input/          Zod input schema, username normalization, mode validation
  domain/         canonical models
  providers/
    instagram-provider.ts
    apify/
    fixture-provider.ts
  normalize/      content derivation, coercion, dedupe, filtering
  scoring/        signals, transforms, redistribution, confidence, classification
  pipeline/       orchestration
  output/         ranking and schema-valid result builders
  monetization/   Pay-Per-Event preflight and final charging

Raw Store Actor keys do not escape the Apify provider adapter layer. The deterministic scoring engine works only with normalized domain models.

Provider fallback

The primary content provider is apify/instagram-post-scraper.

On genuine primary failure only, the Actor falls back to apify/instagram-scraper with resultsType: "posts".

Fallback-sourced records receive a confidence penalty. The fallback does not run simply because an account has no recent posts.

Cost-safe retries

A downstream Actor is started once per invocation. Its run ID is retained, and polling/dataset reads are retried against that same run so transient failures do not accidentally create duplicate paid runs.

A start is retried only where the system has evidence that no run was created. Ambiguous failures are not blindly retried.

---

Local development

Requires Node.js 20+.

$npm install

APIFY_TOKEN

Required only for local live runs and fixture recapture. Never commit it.

cp .env.example .env
# then edit .env

On the Apify platform, the runtime token is injected automatically.

Useful commands

npm run dry-run
npm test
npm run typecheck
npm run lint
npm run build

npm run dry-run executes the real normalization, scoring, and output-building pipeline against captured fixtures without consuming live Apify credit.

---

Deployment

apify login
apify push

apify login associates the CLI with the Apify account you authenticate as. apify push creates or updates the Actor under that account using .actor/actor.json.

No source file hardcodes a production account, Actor ID, Dataset ID, or key-value store ID.

For API integrations, short analyses can use the synchronous endpoint. Larger analyses should start an asynchronous run and read the resulting Dataset/OUTPUT after completion.

POST /v2/acts/<username>~instagram-viral-content-intelligence/run-sync-get-dataset-items
POST /v2/acts/<username>~instagram-viral-content-intelligence/runs

---

Testing

$npm test

The test suite covers:

• input normalization and validation
• weighted engagement
• baseline rules and engagement-basis comparability
• transform calibration
• every score signal
• weight redistribution and unearned-weight semantics
• confidence penalties
• classification boundaries
• provider adapters and fallback behavior
• paid-run start idempotency
• cross-provider deduplication
• collaboration analysis
• baseline coverage
• NO_RECENT_POSTS semantics
• structured output schemas
• Pay-Per-Event configuration, budget preflight, idempotency, and exact-charge validation

Captured fixtures are regenerated only through the repository's capture tooling and should not be hand-edited.

---

Disclaimer

Viral Intelligence AI is an independent third-party product.

This Actor is not affiliated with, endorsed by, sponsored by, or operated by Instagram or Meta. Instagram and Meta are trademarks of their respective owners.

Users are responsible for using this Actor and its output in accordance with applicable laws, platform terms, and their own compliance requirements.