[INTERNAL] Fullstory — CarGo Campaign Performance

run talk-track --asset=cargo-campaign-performance

The Core Frame

Lead with the structural argument, not the numbers. Executives will ask "so what" faster than you think — have the answer ready in one sentence.

// PRIMARY ARGUMENT

Campaigns are 8.6% of traffic but 62% of revenue. They're not the problem — they're the multiplier. The real conversation is where to concentrate that multiplier and which product issues are capping its ceiling.

ProductPage traffic is down 38% in the last two weeks, but UTM-tagged traffic is only down 26%. Campaigns are actually holding up better than organic/direct. UTM-tagged users fire Revenue Events at 7.3× the rate of non-UTM traffic. The takeaway isn't "marketing is failing" — it's "marketing is the highest-leverage channel we have, and here's how to get more out of it."

// THE NUMBERS

The three numbers that anchor the entire conversation

7.3× — UTM users vs non-UTM users for revenue conversion
62% — of Revenue Events come from UTM-tagged landings
27.6% — top campaign (vip_launch_2025) landing → revenue rate

// WINNERS

What's working — and deserves more budget

vip_launch_2025: 37.9% to PDP, 27.6% to revenue — best in class
Newsletter source: 19.8% landing-to-revenue, 9.9× site baseline
summer_sale_2024: still converting at 19.4% into 2026 — seasonal creative that has legs

// LAGGARDS

What needs to be cut or reworked

holiday_promo_2025 — 19.1% PDP rate, temporally off in April
affiliate_2025 — 1,528 landings but only 19.4% convert to PDP
seasonal and electric_rental — both at ~20%, small and underperforming

// PRODUCT CEILING

The part nobody's talking about: the ceiling is product, not marketing

Brand-new JS regression (+345%) in main.js — deploy issue
Purchase Complete button errors (+100%, 26 users) — terminal failure
City inventory API worse in Austin (+107%), St. Louis (+176%), Raleigh (+94%)
Fix these and every campaign's conversion rate moves up simultaneously

// STOPPER

If leadership pushes back with "these rates seem low"

Baseline landing-to-revenue for all users is 2.0%. Campaigns are 14.6%.
Newsletter: 19.8% to revenue. Google CPC: 14.4%. These are strong numbers.
Numbers are currently depressed by product issues — real ceilings are higher
This is Fullstory MCP data, not a survey or a model — it's observed user behavior

cat numbers-cheatsheet.txt

Numbers Cheatsheet

Must-memorize before the meeting. Group by theme — if someone cuts you off, pivot to the next group.

# 2-week comparison

ProductPage Views

−38%

12,237 current vs 19,719 prior

All UTM landings

−26%

6,434 current vs 8,742 prior. Campaigns holding up 12pp better than overall.

UTM share of PDP

+2.1pp

13.0% now vs 10.9% prior — campaigns gaining share

# Full funnel (30d, unique users)

UTM users → PDP → Checkout → Revenue

13,272 → 3,159 → 2,060 → 1,933

100% → 23.8% → 15.5% → 14.6% landing to revenue

All users → PDP → Checkout → Revenue

154,141 → 12,749 → 3,544 → 3,117

100% → 8.3% → 2.3% → 2.0% landing to revenue

UTM revenue lift

7.3×

14.6% UTM vs 2.0% baseline. 62% of Revenue from UTM.

# Campaign leaderboard (30d)

Top by reach rate

vip_launch_2025

37.9% to PDP · 27.6% to revenue · 909 / 646 users

Top by volume

cargo_rental_2025

4,677 landings · 24.8% of UTM PDP share · only 10.8% to revenue

Bottom four (<20% PDP rate)

holiday / affiliate / seasonal / electric

Candidates for budget pull or creative rework

# Source & medium winners

Newsletter (source)

30.0% / 19.8%

PDP rate / Revenue rate. 9.9× site baseline. Beats Google on both.

Google (source)

25.1% / 14.4%

Higher volume (5,456 landings) but lower efficiency than newsletter

Email medium vs CPC

29.1% vs 24.1%

PDP reach rate. Email outperforms CPC across the board.

# Product regressions (non-campaign)

New JS error in main.js

+345%

TypeError: n is not a function · 48 users · looks like a deploy regression

Purchase Complete error clicks

+100%

26 users · terminal checkout button failing · direct revenue loss

City API worse in 3 markets

+94% to +176%

Austin, St. Louis, Raleigh · 417 users total

cat presenter-notes.md

Section-by-Section Presenter Notes

Scripted bullets aligned to each section of the full report. Suggested timing in parentheses — adjust to audience appetite.

# Opening — Hero + Stats Strip (1 min)

// presenter bullets

Open with the paradox — "ProductPage traffic is down 38%, but UTM campaigns only lost 26%. Campaigns are holding up." This is the hook.
Stats strip — Point at "7.3×" first. That's the most compelling single number in the entire report. Everything else supports it.
Don't read the hero tags aloud — they're redundant with what you'll say. Let them render.
Don't dwell on the decline — If you spend 5 minutes on the −38%, the meeting becomes about the decline, not the campaign decisions. Acknowledge it, pivot to "what's working."

# Section 01 — Two-Week Comparison (2 min)

// presenter bullets

The ProductPage daily chart tells the story — Purple (prior) bars are uniformly taller than green (current). The partial-day dashed bar at the far right is today — note it's a half-day.
The UTM chart is more encouraging — Much less degraded than PDP overall. This is visual proof of the "campaigns holding up" claim.
The 12-point gap — PDP −38% minus UTM −26% = 12pp gap. That gap is the non-campaign decline. Organic, direct, referral. Not the marketing team's lane.
If asked "when did the decline start?" — point at the last week of the current window; bars go 636, 251, 690 — something happened around Apr 13. Worth a follow-up.

# Section 02 — Campaign Leaderboard (3 min)

// presenter bullets

Read the table two ways — Reach Rate is creative/targeting quality. Share of PDP is volume contribution. Different campaigns win on each.
Spotlight vip_launch_2025 — 37.9% is the best rate in the portfolio. 1.5× the portfolio average. Whatever this campaign is doing is the pattern to replicate.
Spotlight cargo_rental_2025 — Biggest volume, mediocre rate. Not a failing campaign — a campaign with room to grow if we can lift its rate.
Call out the bottom four — All below 20% rate. Holiday campaign in April is the most obvious — acknowledge it and propose pausing.
Don't read every row aloud. Scroll down the table pointing at the colored conv-rate cells. Green-orange-red tells the story visually.

# Section 03 — Revenue Funnel (3 min)

// presenter bullets

This is the most important section — The side-by-side funnel is the single chart that reframes the whole conversation from "marketing performance" to "marketing ROI."
Walk through the UTM funnel step by step — 13,272 landed, 23.8% reached PDP, 65% of those reached Checkout, 94% of those fired Revenue. Each step is a smaller relative drop.
Compare to "All users" — Same structure, wildly different rates. The funnel shape is similar; the baseline is just much lower for non-campaign traffic.
The 7.3× multiplier — State it explicitly. "A UTM-tagged user is 7.3× more likely to complete a purchase than someone arriving without a UTM."
Per-campaign revenue table: highlight vip_launch's 27.6% vs cargo_rental's 10.8%. Same absolute revenue count (646 vs 425), but vip_launch does it on 40% fewer users.

# Section 04 — Source & Medium (1.5 min)

// presenter bullets

Newsletter beats Google — Same number of revenue conversions from 15% fewer users. Email medium 29.1% vs CPC 24.1%.
If leadership is email-skeptical, frame it as "we have an under-utilized owned channel that outperforms paid search."
Keep this section short — it's a drill-down into channel mechanics. The executive takeaway is just "email is undervalued."

# Section 05 — Winners & Laggards (1.5 min)

// presenter bullets

This is the prose version of Section 02 — Use it to slow down on the two campaigns leadership should remember: vip_launch (extend) and cargo_rental (audit).
The Laggards card is where you propose the budget cut — Four campaigns, sub-20% rate, all clear candidates for pause or rework. No debate needed if they agree on the methodology.
Leadership will often want to defend cargo_rental because it's "performing" in absolute terms. Acknowledge that — then point out the rate ceiling.

# Section 06 — Non-Campaign Friction (2.5 min)

// presenter bullets

Open with the frame — "These issues aren't marketing's problem, but every one of them caps marketing's ROI." This is how you avoid inter-team friction during the meeting.
New regressions table — Lead with the TypeError (+345%). Brand new, in main.js, suggests a recent deploy. This is the item that should get a specific engineering owner by end of meeting.
Purchase Complete button errors — 26 users hitting the terminal button and getting an error is pure lost revenue. Use the word "terminal" — it's more alarming than "checkout."
Share button fix — Trivial CSS change, affects 968 users on PDP. Good "easy win" to close the section on.
Cross-link the CarGo UX Report for the Wall 1 / Wall 2 baseline. If leadership is new to this, this is the second meeting about these issues.

# Section 07 — Recommendations (4 min)

// presenter bullets

The two rec-cards are deliberately separate — Product fixes and marketing moves have different owners. Don't blur them. Marketing shouldn't own the deploy regression; engineering shouldn't own the budget reallocation.
P1 marketing moves — Pause bottom four, extend vip_launch. If you only get two decisions out of this meeting, these are the two.
P1 product fixes — TypeError, Purchase Complete, city APIs. If you get a third decision, get an engineering DRI for these.
P4 attribution instrumentation — This is the ask for next-cycle investment. Flag it explicitly — "we can do better analysis next quarter if we instrument utm_campaign as a page variable."
Close with: "We can re-run this entire analysis in 2 weeks. The MCP turned hours of SQL into minutes of questions — this is not a quarterly report anymore."

cat discovery-questions.txt

Discovery Questions

Use these to surface context the report doesn't have. Each is tagged by who should answer it.

Marketing

What's the brief, creative, and targeting for vip_launch_2025 — and can we reuse it as a template for a parallel campaign?

opens: scaling

A 37.9% PDP rate and 27.6% revenue rate is 1.5× to 2.6× the portfolio average. Something about this campaign's audience, copy, or landing experience is working much harder than elsewhere. If the team can document it, we can run a second parallel campaign (different audience, same playbook) and measure the incremental contribution.

If they say...

"We already maxed out that audience" → OK, but the pattern (creative + landing) may generalize to adjacent audiences. Let's test.
"We don't know what made it work" → That's the more common answer. Then the next step is diagnostic — look at referrer breakdowns, landing page, and ad creative in one doc.

Marketing

Why is holiday_promo_2025 still running in April? Is there budget lock-in, or is this a residual spend we can reclaim?

opens: reallocation

A "holiday" campaign running 3+ months after the holiday is usually either (a) spend that never got paused, (b) branded creative that's still delivering mild brand lift, or (c) a creative refresh that's just named poorly. Need to know which to decide if it's a clean cut or a rename.

If they say...

"It's on auto-renew" → Pause it; redirect budget to vip_launch or newsletter cadence.
"It's actually Q2 creative we mislabeled" → Fine — but then the UTM needs to change too, or we'll keep misattributing.

Engineering

Was there a deploy to main.000620b5.js in the last 2 weeks? The "TypeError: n is not a function" error is brand new (+345%).

opens: regression diagnosis

The bundle hash is specific (main.000620b5.js). If engineering can confirm when that hash was deployed, we have a deploy window. The error signature is a minified function call — needs a source map to get a real traceback. 48 users per 2w is small but climbing.

If they say...

"We shipped a frontend release on [date]" → Correlate the error spike to that date. If they line up, roll back or hotfix.
"No recent deploys" → Then it's either a dependency update or a data-triggered code path. Still worth a source-map lookup.

Engineering

Is there an alert on the [SH] Purchase Complete button error-click rate? 26 users hit an error on the terminal checkout action in the last 2 weeks — zero prior.

opens: monitoring gap

This is the final click in the purchase flow. Any error here is lost revenue — and the fact that it went from 0 to 26 users suggests a recent change. A P1-level alert should have fired. If there's no alert, that's a secondary finding: add one.

If they say...

"We don't have per-element error monitoring" → That's the finding. The Fullstory signal exists; it just needs a threshold and a notifier.
"We have monitoring but it didn't fire" → Threshold is too permissive. Tighten it.

Engineering

The /v2/cars/getAllCarsInOrgInCity endpoint is degrading in Austin, St. Louis, and Raleigh. Is there a partition or shard that handles these cities?

opens: infra

Three specific cities regressing together suggests shared infrastructure — a region, a shard, a data source. If this endpoint is partitioned geographically, the fix might be isolated to that partition. This was a known issue in the prior UX report and it got worse.

If they say...

"These cities share a backend" → Narrow the investigation to that backend — capacity, config, upstream data.
"They're all independent" → Then it's a coincidence of three regressions in two weeks — which is less likely than you'd think. Worth investigating why the timing lines up.

Data / Analytics

The Revenue Event fires for 1,933 UTM users but only 2,060 UTM users hit a URL with "checkout" in the path. That's 93.8% — can you confirm how Revenue Event is wired?

opens: definition sanity

The ratio is suspiciously tight. Revenue Event may be firing server-side or from a confirmation URL outside the checkout pattern. If the definition is wrong, we're over- or under-counting. Need to confirm before using these rates in any exec-level comms.

If they say...

"It fires on the /confirmation page" → OK, that's why it's not filtered by URL-contains-checkout. Definition is fine.
"It's a server-side API push after the payment succeeds" → Also fine. Doc it in the methodology.
"We don't really know" → Flag this before socializing the report further.

Marketing Ops

Can we push utm_campaign into the Fullstory page variable on every SPA route, not just the landing page URL?

opens: instrumentation upgrade

Right now UTM attribution only works on the landing URL. Once the user SPA-navigates, the UTM leaves the URL and we lose per-page attribution. Pushing utm_campaign into window.FS.setVars("page", ...) on every route would unlock per-campaign day-level metrics — including exact 2-week comparisons per campaign, not just per-portfolio.

If they say...

"We can do it — just needs a tag manager change" → Ship it. ~1 day of work for 10× better attribution data.
"It requires a frontend deploy" → Still small — one line in the router effect.

Exec / Leadership

If we could move every UTM campaign's conversion rate up 5pp by fixing the product issues in Section 06, what's the revenue impact?

opens: business case for product fixes

Framing the product fixes in revenue terms converts "engineering backlog" into "quarterly OKR." 5pp on 1,933 revenue users is ~97 more revenue events per month. Multiply by deal size. Use this to justify prioritization.

If they say...

"We don't have AOV data" → That's a separate tracking gap. Propose a follow-up.
"That's a big assumption" → Acknowledge — it's a rough estimate. Still orders of magnitude bigger than the cost of the fixes.

grep -r "pushback" ./cargo-campaign-performance/

Stakeholder Pushback Handlers

The five challenges you'll hear. Response + reframe for each.

These conversion rates seem too high. 14.6% landing-to-revenue isn't what we see in our own dashboards.

// CMO / Marketing Leader

// response

Two things. First, this is UTM-tagged users only — a self-selected, highly qualified cohort. They clicked an ad or tapped an email link. That's already the top decile of intent. Second, CarGo is a demo environment — some portion of the Revenue Event firings are internal, scripted, or QA traffic. Real production numbers will differ. The relative ratios (vip_launch vs cargo_rental, newsletter vs google) will hold across environments — the absolutes won't.

// frame

"The absolutes are environment-specific. The ratios are directional. Use the ratios — they're what tell us where to spend."

How is this different from GA4 attribution? Why should we trust this over our existing reporting?

// Marketing Ops / Analytics

// response

GA4 is a model — it applies attribution rules (last-click, first-click, data-driven) on top of observed events. Fullstory is the raw event stream — every page view, every click, every error, with session context. This report uses cohort-based attribution: users who landed with UTM=X, grouped as a segment, and we measured what they did. It's simpler and more transparent than GA4's attribution models, but also less forgiving — it won't credit a campaign that didn't drive a URL-visible UTM.

// frame

"GA4 tells you the attributed outcome. Fullstory tells you the observed behavior. Both have a place. This is observed."

cargo_rental_2025 generates more revenue in absolute terms. Why would we cut it?

// Performance Marketing Lead

// response

We're not proposing cutting cargo_rental_2025. It's contributing 22% of UTM revenue — that's real. The proposal is to audit its landing experience for a rate lift. Its 10.8% revenue rate is below portfolio average; whatever's depressing that rate (landing copy mismatch, slow page, broken CTA) is a compounding loss. A 5pp rate lift would be 115 more revenue events per month without spending another dollar.

// frame

"The biggest campaign with the weakest rate is the biggest optimization opportunity — more than any net-new campaign we'd launch."

If ProductPage traffic is down 38%, why are we talking about campaign tactics instead of emergency mode?

// CEO / GM

// response

Two separate problems, two separate workstreams. Campaigns only explain 12 percentage points of the 38% decline — the other 26pp is non-campaign traffic (organic, direct, referral). That's an SEO or PR or partner-referral problem, not a marketing campaign problem. We're flagging both in this report. The campaign review is actionable today; the organic decline needs its own investigation with the SEO team or whoever owns acquisition outside of paid.

// frame

"Two-thirds of the decline is outside our lane. We flagged it. We need a different team to own that diagnosis."

You're saying product bugs are depressing marketing ROI. That's convenient for marketing.

// Product / Engineering Lead

// response

The data is the data — it's behavior, not interpretation. 968 users are dead-clicking the share button on PDP. 26 users are clicking the final checkout button and getting an error. 151 users in St. Louis alone hit a network error in the inventory API. These aren't opinions or marketing's framing — they're event counts from Fullstory. Marketing didn't cause them, and product bugs depress every team's metrics, not just marketing's. The point isn't blame. It's that a fix lifts everyone.

// frame

"These aren't marketing's interpretation. They're Fullstory event counts. A fix makes everyone's metrics better — product, marketing, support."

cat investigation-workflow.md

How this report was produced

Fullstory MCP workflow used to generate every number in the full report. Reusable for the next 2-week cycle.

Discover UTM infrastructure

Start with discover_org_context to find available custom variables, defined events, and pages. For CarGo, this surfaced:

utm_campaign, utm_source, utm_medium — all page-scope and user-scope custom variables
ProductPage = page_id 2
Revenue Event defined event = id KSNijoJTTEpe

# Fullstory MCP call discover_org_context(queries=["utm_campaign", "utm_source", "utm_medium", "revenue", "ProductPage"])

Detect UTM landings via URL substring

Dimensioning by the user-scope custom variable didn't work in metric-builder. Substring match on URL worked:
visitedUrl where URL contains "utm_campaign=" → group by DIMENSION_URL_QUERY prefix "utm_campaign=" → returns distribution of campaigns.
Same pattern for utm_source and utm_medium.

# Build top_n metric with URL_QUERY dimension build_metric( query="Count page views where URL contains 'utm_campaign=', grouped by utm_campaign. Top 20.", output_type="top_n" )

Scope to ProductPage visitors via segment

Built a segment: "users who visited page_id 2 in the last 30 days." Attached to the UTM landing metric. Result: UTM distribution of users who actually reached PDP. Repeated for utm_source and utm_medium.

# Build segment + attach to metric seg = build_segment(query="Users who visited page_id 2 in last 30 days") update_metric(metric_id=landing_metric, segment_id=seg.segment_id) compute_metric(metric_id=updated, time_range="last_30_days")

Compute daily trends for 2-week comparison

compute_metric only accepts preset enums (last_7_days, last_30_days, etc.) — no custom date ranges. Workaround: build trend metrics over 30 days, then manually bucket the daily data into current-2w vs prior-2w windows.

# Trend metric with daily frequency build_metric( query="Daily count of ProductPage views, last 30 days", output_type="trend" ) # Sum day-level values manually for each 14-day window

Build per-campaign segments for revenue attribution

For the top 3 campaigns, built individual segments matching utm_campaign=<value> in URL. Attached each to the Revenue Event unique-users metric. Same for top 2 sources. This gives per-campaign landing-to-revenue rates.

# Per-campaign cohorts for campaign in ["vip_launch_2025", "cargo_rental_2025", "summer_sale_2024"]: seg = build_segment(query=f"Users whose URL contained utm_campaign={campaign}") m = update_metric(metric_id=revenue_event, segment_id=seg.segment_id) result = compute_metric(metric_id=m, time_range="last_30_days")

Discover non-campaign friction via discover_groups

Ran discover_groups scoped to Purchase Funnel (id 2BWVg4GQY7Uo) with compare_to_previous=true. Returns frustration signals sorted by delta_pct. Also ran scoped to page_id 2 (ProductPage). Combined output surfaces regressions without manually hunting through signal categories.

# Find signals that spiked vs prior 2w discover_groups( funnel_id="2BWVg4GQY7Uo", compare_to_previous=True, start_time="2026-04-04", end_time="2026-04-17", limit=5 )

Re-run for next cycle

Every metric and segment from this analysis is saved and has a Fullstory URL. To produce the next 2-week report, re-compute the existing metrics with last_30_days, re-bucket the trend data, and re-run discover_groups against the new window. Estimated time: 30 minutes, not days.

ls references/

References & Saved Objects

Quick links to the Fullstory objects that back every number in the report, plus useful external docs.

// saved fullstory objects

📈

ProductPage daily trend

Metric 907915089 · Section 01 chart data source

app.fullstory.com/ui/18PNWR/metrics/create/907915089

📈

UTM landings daily trend

Metric 1495863321 · Section 01 chart data source

app.fullstory.com/ui/18PNWR/metrics/create/1495863321