Browse docs
Sprid docs

Review marketing from connected evidence

Review connected marketing evidence in chat or alongside your local repository.

What this guide does: Investigate acquisition, activation, retention and revenue through the services connected to Sprid, and say plainly what evidence is missing.

Start with the question

Name the app, the date range and the decision the review should inform.

  1. list_apps and list_app_profiles to find the app.
  2. get_marketing_review_context for shared definitions, required investigations, earlier decisions and corrections.
  3. get_marketing_review for the app over two comparable periods. The summary links to full evidence per source (view: "full", sources: [<source>]); omit sources to include social history, store reviews and milestones.
  4. Re-read an exact saved packet with get_marketing_review_evidence and its evidence.id (CLI: sprid marketing-review evidence --id <id> --app <slug>). It still works after a connection changes.

refresh: true asks for live reads; cachedOnly: true reads only stored evidence. Keep returned errors, coverage, population definitions and sample counts in the report.

In a browser chat there is no repository. For a question about a shipped change, ask for a release summary or public changelog and label it as supplied. Never claim to have read a repository or private database. Local users can add repo diffs and database reads through their own tools.

Follow the evidence

list_marketing_queries lists supported reads and their schemas; query_marketing_source runs them with Sprid’s saved credentials. Follow pagination and keep truncation visible. get_documentation with metrics covers definitions and refused calculations; with queries, source-specific reads.

  • Read the PostHog source’s measurement checks before any rate. Each one (a platform whose paywall never sells, payers all placed in the US by the payment integration, a one-country desktop crawler, Apple’s review devices, a signup surface the registration event misses, a dead funnel entry) says a number cannot be read at face value. A platform at zero revenue is not zero demand until its paywall is known to sell.
  • Store impressions by source are listing exposure; downloads by source are acquisition. Do not quote one as the other, and treat every store referrer as a last-click floor.
  • Many email opens with no clicks at all means click tracking is broken, not that nobody clicked.
  • Keep acquisition apart from activation, and people apart from events. A post impression is not an install; a download is not an activated user.
  • Pinterest Pins resurface for months: compare them at equal ages (30, 60 and 90 days). Saves are interest on Pinterest and outbound clicks are people leaving it; neither is a site session or an install. The pinterest source has posts only, with no comments. See Pinterest content and publishing.
  • Compare equal windows and comparable populations.
  • No onboarding events means recommending instrumentation, not guessing a funnel.
  • Keep revenue sources separate until the overlap check says they can be added.

For each finding, test another explanation: tracking changes, traffic exclusions, attribution window, seasonality, a different audience mix. A before/after comparison doesn’t prove cause. If a difference is within normal variation or the sample is small, say so and don’t rank it.

Report and save

Lead with the decision, then the evidence, the limits and what would change the answer. Keep failed reads apart from reads that returned nothing. next_actions gives the follow-up. Check remaining setup, including the saved app icon, voice and relevant connections. Recommend the next useful integration step without repeating completed or explicitly declined setup. A missing credential goes to the secure App Profile form or a CLI key-file command; no provider MCP is needed for a supported query.

  • Shared context: when authorized, save non-secret definitions, investigations, decisions, corrections and release references with save_marketing_review_context, sending baseRevision from the latest read. A conflict returns both versions; reconcile before retrying. Saved context is a claim with references, not verification. CLI: sprid marketing-review context --app <slug> reads, --file <context.json> imports {baseRevision,context}. Private notes stay local.
  • Changes: log confirmed product or marketing changes with add_event, naming the areas they affect and why.
  • The review itself: end every review with save_marketing_review {profile, verdict, agenda: [{title, why}], period: {start, end}, surface: "chat"}: the commercial verdict in a sentence or two and the ranked agenda, most consequential first. It appears on the app’s Reviews page in Sprid and is where the next review starts; list_marketing_reviews reads past ones. Send the verdict and agenda only, never the full report or raw customer rows. A second save the same day replaces that day’s review.

Never store secrets or signed attachment URLs in any of these.

Collection and coverage

  • Sprid refreshes two rolling 30-day windows daily for configured services on active plans, and re-reads late provider exports. No model calls, publishing or paid social reads. Other windows are read on demand.
  • Pause with the App Profile’s metricsCollectionEnabled: false or sprid marketing-review collection --enabled false. Stored evidence stays readable.
  • Snapshots are private to the app, tied to its configuration and kept 90 days. Save local evidence exports for a lasting archive.
  • Missing days stay unknown. Incomplete store or Search Console windows get no percentage change. Never sum daily unique people into a monthly count.
  • configuration_only means identifiers and a key are saved, not that access works. Errors return a safe code, the HTTP status when known, whether to retry and the next step. Retry transient errors before recommending a reconnect. Unsupported metrics and provider privacy thresholds are stated as limits.
Need a hand?
Colour theme
Back to Sprid ↗