Marketing Attribution for Product-Led Growth (2026)

A founder I advise runs a self-serve developer tool, freemium tier plus a $19/mo paid plan, no sales team. Late last year his board asked the reasonable question every PLG board asks: which channels are actually driving paid revenue, and where should we put the next dollar? He pulled up GA4. It told him 38% of his paid conversions came from "Direct." His honest read was that brand was strong and the product sold itself. The actual story, once we split the funnel correctly, was that organic content and AI-engine citations were driving the free signups, those signups were activating and upgrading weeks later through the in-app billing page, and GA4 was crediting the upgrade-day billing-page visit as Direct. He had been about to defund the content that was driving his revenue because the chart said the revenue came from nowhere.

That is the PLG attribution problem in one paragraph. It is not a GA4 bug you can fix in the admin UI, and it is not solved by buying a bigger tool. It is structural to the product-led motion, and it shows up in a specific, predictable shape that this article walks end to end.

This is the PLG-specific companion to the bootstrapped SaaS marketing attribution playbook, which covers general SaaS attribution staged by MRR. That piece is the right starting point if your motion is sales-led or mixed. This one is for the self-serve, free-signup-first, upgrade-later motion specifically, where the classic attribution model fails in ways the general playbook only touches. I have run this architecture on attrifast.com from $0 MRR and stitched it into roughly forty channels across client PLG properties, and the patterns below are what survived contact with production.

Quick Facts

Two numbers do most of the analytical work here. The first is the freemium-to-paid conversion rate of 2-5% per OpenView [1], which is the single fact that explains why PLG attribution is hard — only a sliver of free signups ever produce revenue, and the gap between signup and that revenue is long. The second is the 18-34% AI-engine session share I measure on developer-tools PLG sites in Q1 2026, which explains why the Direct bucket has become a junk drawer that quietly hides the channels driving your signups.

Why product-led growth breaks attribution worse than sales-led SaaS

PLG breaks attribution worse than sales-led SaaS for three specific reasons, and they compound. The visible conversion event (a free signup) is structurally far from the revenue event (a paid upgrade weeks later). Self-serve removes the human in the loop who, in a sales-led motion, asks every buyer how they found you. And AI engines have become a real discovery channel for PLG buyers while hiding inside the Direct bucket. Sales-led SaaS papers over weak measurement with a salesperson; PLG has no salesperson, so the gap is naked.

Let me take each reason in turn, because the fix for each is different.

Reason 1: the conversion you can see is far from the revenue you care about

In a sales-led motion, the conversion event you instrument (a demo request, a "talk to sales" form) is close to revenue and happens in a session you can attribute. In PLG, the event you can see is a free signup, and that is step one of at least three: signup, then activation, then a paid upgrade that lands days or weeks later. The paid upgrade typically happens in a session with no marketing touch — an in-app prompt, a billing-page visit, an email click — so attributing revenue to the upgrade-day session credits the wrong thing every time.

The fourth row is the worst case. A freemium signup can sit free for months and then upgrade when a usage limit finally bites. The marketing touch that drove the signup is now ancient history relative to the revenue event, and any model that attributes on the most recent session is guaranteed to be wrong.

Reason 2: no human in the loop to ask "how did you hear about us"

Sales-led SaaS has a quiet attribution backstop that PLG lacks entirely: the SDR or AE who, on the first call, asks the buyer how they found the product and types the answer into the CRM. That qualitative source data is imperfect (buyers misremember, reps forget to log it) but it is a real signal that anchors the quantitative attribution. In a self-serve PLG motion there is no call, no rep, and no field for the buyer to fill in. The buyer signs up, uses the product, and upgrades, and at no point does a human ask where they came from.

The practical consequence: PLG attribution has to be more rigorous on the technical side precisely because it cannot lean on the human backstop. The first-party click-to-Stripe join is not a nice-to-have for PLG the way it is an optional refinement for sales-led SaaS. It is the entire attribution surface.

One partial substitute is a post-signup "how did you hear about us" micro-survey on the welcome screen. It works, but treat its output as directional. Response rates run 20-40%, free-text answers are messy ("a friend," "Google," "the internet"), and the respondents skew toward the engaged users who would have activated anyway [19]. Use it to sanity-check the quantitative attribution, not to replace it.

Reason 3: AI engines are a major PLG discovery channel that hides in Direct

This is the newest of the three and the one most PLG teams underweight. PLG buyers — disproportionately developers, technical operators, and self-serve software shoppers — increasingly begin product discovery inside ChatGPT, Perplexity, and Claude rather than a Google search box [22]. When one of those engines cites your docs, your comparison page, or your changelog, the user clicks through. The AI client strips the referer header on most of those clicks, so GA4 sees an empty referer and no UTM, and files the visit as Direct/(none) [8][3]. The ChatGPT referral analytics guide walks the mechanics of why this happens in depth; here the point is what it does to PLG attribution specifically.

For a PLG company the Direct row is doubly poisoned. It contains the hidden AI-discovery traffic that drove the free signup, and it contains the in-app billing-page visits where the paid upgrade actually fires. Both land in Direct, so a naive last-touch read concludes that Direct both discovers and converts your users, which is the exact wrong lesson. The discovery happened in AI or organic content; the conversion happened in-app weeks later. Neither is "Direct" in any decision-useful sense.

The honest caveat, stated up front because it matters: the 18-34% AI-engine share is a developer-tools and technical-PLG number. For a non-technical PLG product (a consumer productivity app, a creator tool) the AI share inside Direct is materially lower, often single digits, because the buyers are not doing category research in ChatGPT yet. Measure your own Direct bucket before assuming the rate transfers. The multi-touch attribution for AI search piece covers how to size this on your own site.

The PLG funnel and where attribution must hook in

The PLG funnel has more stages than the sales-led funnel, and attribution has to hook into each one differently. The classic marketing funnel collapses discovery and conversion into a single event; the PLG funnel spreads them across discovery, free signup, activation, the product-qualified-lead threshold, and finally paid conversion. Attribution that only instruments the first and last stages misses the two stages in the middle where most of the predictive signal lives.

Here is the canonical PLG funnel with the attribution hook each stage needs:

The two diagonal hooks on the left (discovery and signup) are the marketing-attribution layer. The two on the right of the middle (activation and PQL) are the product-analytics layer. The bottom join (paid conversion) is where the two layers reconcile through Stripe. Most PLG teams instrument one layer well and the other badly, then wonder why the channel-mix dashboard and the activation dashboard tell different stories. They tell different stories because they measure different stages and were never joined.

The stage-by-stage hook table:

The single most common PLG attribution architecture mistake is hooking attribution into discovery and paid conversion but skipping the activation hook. Without activation you cannot tell whether a channel drives signups that monetize or signups that bounce, and those are the only signups worth funding. The next section is entirely about that distinction.

The drop-off shape across the PLG funnel explains why each stage needs its own measurement. Representative conversion rates between stages for a self-serve PLG product:

The free-signup-to-activation row is the one that leaks most and the one classic marketing attribution never sees, because it happens inside the product, not on the marketing site. That is the structural reason PLG attribution needs a product-analytics layer that sales-led SaaS can sometimes skip.

Free-signup vs activation vs paid: the three things you must measure separately

The core of PLG attribution is recognizing that "a signup" is not one event with one source — it is the start of a journey through three measurable states, and you must attribute each separately or you will optimize the wrong one. Free-signup attribution tells you what drove the top of the funnel. Activation tells you which of those signups reached value. Paid conversion tells you which of those activated users actually paid. Channels rank completely differently on each.

Why this matters in one table, using representative numbers from a PLG audit:

Read the paid-social row against the organic-content row. Paid social drove the most signups of any channel (1,400) and the fewest paid customers per signup (1.9%) because its signups barely activate (18%). Organic content drove fewer signups (1,200) but more than 3x the conversion rate, because the users who arrive from a deep technical article are pre-qualified and activate at 41% [17]. If you optimized on the signup column — the column GA4 makes easiest to see — you would pour budget into paid social and starve the channel actually driving revenue. The activation rate is the column that separates them, and it lives in your product analytics, not your marketing dashboard.

Free-signup attribution: the top-of-funnel layer

Free-signup attribution answers "what drove the account creation." It is the most straightforward of the three because the signup is a single event you can capture in the session. The model is first-touch-on-signup with the source persisted on the user record at account creation.

Activation: the product-analytics layer

Activation is the moment a new user reaches your product's core value — the aha moment. It is not a marketing event and not a Stripe event; it is a product event, and it belongs in your product-analytics tool. Amplitude's PLG research [12] is consistent that activation is the strongest single predictor of paid conversion, stronger than signup source. The hard part is defining your activation event honestly.

The activation definition is a product decision, not an analytics decision, and getting it wrong corrupts the entire PLG attribution chain. Define it as the earliest event that reliably predicts retention, validate it against your own cohort data, and revisit it as the product changes. Reforge's PLG material [14] and Lenny's Newsletter's growth writeups [15] both stress that a too-shallow activation definition (e.g., "completed onboarding") flatters your numbers and predicts nothing.

Paid conversion: the Stripe join

Paid conversion is the revenue event, and it is where the marketing and product layers reconcile. The model is to join the eventual paid upgrade back to the original signup source, captured weeks earlier, via the Stripe webhook — not to the session in which the upgrade happened.

The implementation specifics for the Stripe join:

The Stripe metadata propagation footgun is worth repeating because it is the single most common PLG attribution bug I see in production. Stripe metadata does not automatically copy from the Checkout Session to the Subscription or Customer object [10][20]. If you set attrifast_session_id on the Checkout Session and then read it on the customer.subscription.updated webhook, it is not there. You have to set it explicitly on the Customer or Subscription object too. The fix is two lines of code and it is the reason most homegrown PLG attribution silently credits everything to Direct.

The right Stripe events for a PLG funnel:

For freemium, the upgrade often arrives as a fresh checkout.session.completed (the user was never on a Stripe trial, they were on your app-side free tier). For card-required trials, it arrives as a customer.subscription.updated transition from trialing to active [21]. A robust PLG attribution layer listens to both and joins each to the stored signup source.

AI as a PLG discovery channel: the new hidden one

AI engines are now a meaningful PLG discovery channel, and they are structurally invisible in GA4 because the AI client strips the referer on most outbound clicks. For PLG specifically this matters more than for any other motion, because PLG buyers skew toward exactly the technical, self-serve, research-heavy users who have moved their product discovery into ChatGPT, Perplexity, and Claude. The discovery happens in the AI engine; the click arrives with no referer; GA4 files it as Direct; and the free signup it produces gets attributed to nothing.

The mechanics, in brief, since the ChatGPT referral analytics guide and track ChatGPT traffic cover them at length:

Why PLG over-indexes on AI discovery, in a table:

The practical detection model for AI-as-PLG-discovery is the same four-layer pattern from the ChatGPT guide: UTM tags on URLs you publish, bot exclusion by user agent [4], referer fingerprinting against a known AI-domain list, and behavioral inference on no-referer deep-page entries. For PLG the behavioral-inference layer is especially valuable because PLG buyers land on docs and comparison pages — exactly the deep, FAQ-shaped, question-answering pages that AI engines cite.

The payoff for PLG is concrete. Once AI is split out of Direct, the free signups it drives become a measurable cohort, and you can run them through the same activation and paid-conversion analysis as any other channel. Representative numbers for AI-engine PLG signups versus organic search across the technical-PLG sites I measured in Q1 2026:

In the audits I have run, AI-engine PLG signups activate and convert at rates comparable to or slightly above organic search, because an AI citation pre-educates the user the same way a good article does. The honest caveat, again: this is a Q1 2026 snapshot on technical-audience PLG, the behavioral-inference layer has bounded uncertainty (roughly 78-86% precision in my measurement), and you should re-measure quarterly as engine behavior shifts.

The SMB PLG attribution stack, by MRR

PLG attribution sophistication should track MRR stage the same way general SaaS attribution does, but the stack composition differs because PLG always needs a product-analytics layer for activation, which sales-led SaaS can sometimes skip. Below is the staging I use for self-serve PLG companies.

Stage 1: $0-5k MRR — do not buy attribution software

Below $5k MRR your free-signup volume is too low and your paid-conversion count too small for any per-channel attribution number to be statistically meaningful. With 40 paying customers split across 7 channels you have 5-6 per channel, which is noise. The honest stack at this stage is a welcome-screen "how did you hear about us" survey, a spreadsheet that joins those answers to Stripe MRR, and PostHog's free tier for activation [18]. Tomasz Tunguz [6] and the early-stage growth canon, including Lenny's Newsletter [15] and SaaStr [17], consistently argue that customer conversations beat attribution dashboards at this scale, and for PLG that is doubly true because your activation definition is still in flux.

Stage 2: $5-50k MRR — Stripe-native attribution plus a product-analytics tool

This is where a Stripe-native attribution tool starts to pay for itself, and where the PLG-specific architecture (free-signup-to-paid join plus AI-channel split plus activation tracking) becomes worth wiring properly. The two-layer stack is the point: a $29/mo attribution tool for the channel-to-revenue side and a product-analytics tool for the activation side, reconciled through Stripe.

What you should not yet measure at this stage:

Stage 3: $50-500k MRR — first-party attribution plus AI split plus paid product analytics

At this stage the free-signup volume is high enough that channel numbers stabilize, and the activation layer becomes a serious optimization surface. This is also where a hybrid PLG-plus-sales motion often emerges (a sales-assist team chasing PQLs), which adds an account-level dimension. The stack expands to a paid product-analytics tool and, if the sales-assist motion is real, the beginnings of PQL scoring.

The "only if warehouse" qualifier on reverse ETL matters; most $50-500k MRR PLG companies do not need a warehouse yet. The tilt toward warehouse infrastructure comes when you have more than one revenue motion (self-serve plus sales-assist plus expansion) or conflicting numbers across two product-analytics tools.

Stage 4: $500k+ MRR — enterprise warehouse attribution, where Dreamdata wins

This is where I will be honest about where the enterprise tools beat the cheap stack, because the alternative — pretending Attrifast is the right answer at every scale — would be dishonest. Above roughly $50k MRR with a hybrid PLG-plus-sales motion, and unambiguously at $500k+ MRR, Dreamdata and the enterprise warehouse stack win on three things the cheap stack cannot do well.

Dreamdata's entry pricing sits north of $750/mo as of mid-2026 [9], the kind of spend that only pencils against the six-figure channel budgets the enterprise go-to-market benchmarks describe [16]. Against a $30k MRR self-serve PLG business with no sales team, that is the wrong tool for the problem — the account-level resolution and warehouse joins it provides solve problems that business does not have yet. Against a $1M+ ARR hybrid PLG company with a sales-assist team chasing PQLs across a multi-stakeholder account, it is the right tool and the cheap stack would break. The progression is cheap-and-Stripe-native first, enterprise-warehouse later, and the crossover is somewhere around $50-100k MRR depending on whether you run a sales-assist motion. The general-SaaS staging in the bootstrapped SaaS playbook covers the non-PLG version of this same curve.

Tool comparison: Amplitude, Mixpanel, Dreamdata, and Attrifast for PLG

The constant category confusion in PLG tooling is between product-analytics tools (Amplitude, Mixpanel, PostHog, Heap) and attribution tools (Attrifast, Dreamdata, Factors.ai). They sit in different layers of the PLG stack and solve different problems. Buying a product-analytics tool expecting marketing attribution, or vice versa, is the most common PLG tooling mistake I see.

The decisive read: no single tool does both layers of PLG attribution well, and the marketing claims that one does are the ones to distrust. The right shape is one product-analytics tool plus one attribution tool, reconciled through Stripe.

Amplitude and Mixpanel deserve a specific note because they are the tools PLG founders most often try to stretch into attribution. They are superb at the activation and retention side — Amplitude's PLG research [12] is some of the best public material on activation — and they are the right product-analytics layer for most PLG companies. They are not channel-to-revenue attribution tools and they do not natively join Stripe revenue to marketing source. The product analytics vs revenue tracking comparison walks this distinction in full. Use them for the funnel they own and add a Stripe-native attribution tool alongside.

Setting up PLG attribution: the practical workflow

This is the practical setup for a $5-50k MRR self-serve PLG SaaS. The article cannot pretend the author has no interest — Attrifast is the attribution tool I built for this stage — but the architecture decisions below are the ones that matter regardless of whether you use Attrifast, a competitor, or a homegrown build.

Step 1: Connect Stripe via OAuth (5 minutes). Read-only access to Stripe events, no API key handling. The connection authorizes reading customer.subscription.*, invoice.payment_*, and checkout.session.* events, which is everything the free-signup-to-paid join needs.

Step 2: Install the cookieless tracking script (3 minutes). A 4KB script in your site head, setting a first-party session identifier scoped to your domain, no third-party requests.

<script defer src="https://attrifast.com/v1/track.js" data-site="your-site-id"></script>

Step 3: Persist the source onto the user record at signup (the PLG-critical step). This is the step that separates working PLG attribution from broken PLG attribution. When the user creates an account, write the first-party session identifier and first-touch source onto your user record so it survives until the upgrade weeks later.

// On account creation in your app backend
await db.user.create({
  data: {
    email,
    attrifast_session_id: req.cookies.attrifast_sid,
    attrifast_first_touch: req.cookies.attrifast_first_touch,
    signed_up_at: new Date(),
  },
})

Step 4: Carry the identifier into Stripe metadata at upgrade (5 minutes). When the free user upgrades, set the stored identifier on the Stripe Customer and Subscription, not only the Checkout Session, so the webhook can read it.

const session = await stripe.checkout.sessions.create({
  // ... your config
  customer_update: { name: 'auto' },
  subscription_data: {
    metadata: {
      attrifast_session_id: user.attrifast_session_id,
      attrifast_first_touch: user.attrifast_first_touch,
    },
  },
  metadata: {
    attrifast_session_id: user.attrifast_session_id,
    attrifast_first_touch: user.attrifast_first_touch,
  },
})

Step 5: Map your paid-conversion event (5 minutes). For card-required trials this is customer.subscription.updated with the status transition trialing to active. For freemium upgrades it is usually a fresh checkout.session.completed. Configure the attribution tool to listen to whichever your funnel uses (or both).

Step 6: Wire your activation event into product analytics (separate, 1-2 days). Define your activation event honestly (the earliest event that predicts retention), instrument it in Amplitude, Mixpanel, or PostHog, and break the activation rate down by acquisition source so you can see which channels send users who reach value.

Step 7: Verify the full loop with a test conversion (10 minutes). Sign up with a known UTM, activate, upgrade, and confirm the paid conversion attributes to the original UTM source — not to Direct or in-app. This is the step most teams skip and the step that catches the Stripe-metadata-propagation bug.

Step 8: Review weekly (ongoing, 30 min/week). The four PLG views worth checking:

That is the full PLG workflow. The deliberate design choices — cookieless, first-party, Stripe-native, source-persisted-on-user-record, activation-tracked-separately — exist to handle exactly the three structural problems from the top of this article. The revenue attribution feature page and the Stripe integration page walk the product side, and the bootstrapped SaaS page covers the positioning for sub-$50k-MRR founders.

Common PLG attribution mistakes I see

Ten mistakes I have seen often enough in PLG specifically to call them patterns, with the fix for each.

Mistake 1: Attributing the paid upgrade to the upgrade-day session. The marketing touch that drove the free signup happened weeks earlier. Crediting the in-app billing-page visit or the upgrade-day Direct session is the single most common PLG attribution error. Fix: persist the signup source on the user record and join back to it on the Stripe subscription event.

Mistake 2: Optimizing channels on signup volume instead of revenue per signup. Paid social often drives the most signups and the fewest paying customers because its signups barely activate. Fix: rank channels by revenue per signup or signup-to-paid rate, never by raw signup count.

Mistake 3: Skipping the activation layer entirely. Without activation you cannot tell a monetizing signup from a tire-kicker. Fix: instrument an honest activation event in product analytics and break it down by acquisition source.

Mistake 4: Defining activation too shallow to predict anything. "Completed onboarding" flatters the dashboard and predicts no retention. Fix: define activation as the earliest event that reliably predicts retention, validated against cohort data, per Reforge [14] and Amplitude [12].

Mistake 5: Letting AI discovery stay buried in Direct. For technical-audience PLG, a large slice of Direct is AI-engine clicks with stripped referers. Fix: split Direct by behavioral signal and attribute the AI cohort, then join it to revenue.

Mistake 6: Setting Stripe metadata on the Checkout Session only. It does not propagate to the Subscription or Customer, so the webhook fires without it. Fix: set metadata explicitly on the Customer and Subscription objects.

Mistake 7: Using GA4 as the revenue source of truth. GA4 understates revenue 18-35% versus Stripe, and it lumps AI discovery and in-app upgrades both into Direct. Fix: Stripe is the revenue source of truth; GA4 is at best a traffic source.

Mistake 8: Jumping to multi-touch attribution too early. Below ~250k MRR, multi-touch produces noisier channel-budget signals than a clean first-touch model. Fix: first-touch-on-signup with a last-non-direct overlay until conversion volume justifies position-based.

Mistake 9: Using a product-analytics tool as the attribution layer. Amplitude and Mixpanel do not natively join channel source to Stripe revenue. Fix: two layers — product analytics for activation, a Stripe-native tool for channel revenue.

Mistake 10: Capping the freemium attribution window too short. A 30-day window misses freemium users who upgrade months later, dumping them into "out-of-window." Fix: cap the window at 90-180 days for freemium and persist the original source permanently on the user record.

What changes about your PLG analytics when you fix this

The shape of the monthly PLG review changes once free-signup attribution, activation, and the paid join are wired correctly. The before/after framework I share with PLG customers:

The content-prioritization row carries the most leverage for PLG. The page-by-revenue list looks completely different once AI is split out of Direct and signups are joined to revenue. Long-tail docs and comparison pages that GA4 ranked near zero often turn out to be the top signup-and-revenue drivers, because they are exactly what AI engines cite and what high-intent self-serve buyers read before signing up. Defunding those pages because GA4 says they get few clicks is the unforced error that PLG attribution exists to prevent.

What this looks like inside Attrifast

A short note on the product, because the article cannot pretend the author has no stake. Attrifast is the Stripe-native attribution tool I built for the $5-500k MRR PLG stage where Dreamdata is too heavy and GA4 is too inaccurate. The five things it does for PLG specifically:

Attrifast owns the channel-to-revenue layer. It does not replace your product-analytics tool for activation and retention — pair it with Amplitude, Mixpanel, or PostHog for that side of the funnel. Pricing is $29/mo for the entry tier, cookieless, Stripe via OAuth. The first-person reason I built it: I was the self-serve founder staring at a GA4 chart that said 38% of my paid conversions came from Direct, knowing the discovery had happened in organic content and AI engines and the upgrade had happened in-app, with no tool at the SMB end of the market doing the free-signup-to-paid join correctly. Attrifast is that tool.

Limitations

Five things this article does not cover, and you should not extrapolate past.

• Account-level attribution for hybrid PLG-plus-sales. When a buying committee of several users maps to one paying account, the right unit of attribution is the account, not the user. This article focuses on pure and lightly-assisted self-serve PLG. For account-level attribution at scale, Dreamdata and Factors.ai are the right tools and the architecture differs from what is described here.
• The 18-34% AI-engine share is a technical-audience snapshot. It is a Q1 2026 number for developer-tools and technical PLG. Non-technical PLG products see materially lower AI shares. Measure your own Direct bucket; do not import the number.
• Activation definition is product-specific and unstable. The right activation event depends on your product and changes as the product changes. The examples in this article are illustrative, not prescriptive. Validate against your own retention cohorts and revisit quarterly.
• Behavioral AI-inference has bounded uncertainty. The no-referer behavioral classifier runs roughly 78-86% precision in my measurement. It is far better than the GA4 default of "all of this is Direct," but it is an inference, not ground truth. Treat the AI cohort as a confident estimate with an error band.
• Cross-device PLG journeys remain an undercount. A user who discovers on mobile via an AI answer and signs up on desktop later looks like two users without identity stitching. The cookieless single-domain approach here does not fully solve cross-device; treat it as a known undercount and verify consent rules with privacy counsel for your jurisdiction.

FAQ

Why does product-led growth break marketing attribution worse than sales-led SaaS?

Three structural reasons compound in PLG that sales-led SaaS avoids. First, the visible conversion (a free signup) is far from revenue — the paid upgrade lands days or weeks later, often in a session with no marketing touch attached. Second, self-serve means there is no SDR or AE in the loop to ask the buyer "how did you hear about us," so the qualitative backstop that sales-led teams lean on does not exist. Third, AI engines have become a major PLG discovery channel and they hide inside the Direct bucket because the AI client strips the referer header. Sales-led SaaS papers over weak attribution with a human in the loop; PLG has no human, so the measurement gap is naked.

What is the right attribution model for a self-serve PLG funnel?

A three-stage join, not a single model. Stage one: attribute the free signup to its acquisition source using first-party first-touch capture. Stage two: track activation (the aha-moment event) as a product-analytics milestone, because activation predicts paid conversion far better than the signup source alone. Stage three: join the eventual paid upgrade back to the original signup source via a Stripe webhook rather than crediting whatever the user did the day they upgraded. The common failure is attributing the paid conversion to the in-app upgrade click or the billing-page direct visit, which credits "direct" or "in-app" for what was actually an organic-content-driven signup six weeks earlier.

How do I attribute a free signup that converts to paid six weeks later in a PLG model?

Persist the first-touch source and a first-party session identifier on the user record at signup, then on the Stripe subscription.created or subscription.updated (trialing to active) event, join the paid conversion back to that stored source rather than the most recent session. The pragmatic window for PLG is 90 to 180 days because freemium-to-paid journeys run long. Cap the window, write the original source permanently to the user record, and accept that conversions beyond the cap get bucketed as out-of-window rather than mis-credited. Attrifast does this join on the Stripe webhook by default; rolling it yourself is a weekend of Next.js middleware plus webhook handling.

Is AI really a meaningful PLG discovery channel or is that hype?

It is real and it is structurally hidden. PLG buyers — especially developers and technical operators — increasingly start product discovery inside ChatGPT, Perplexity, and Claude rather than Google. When one of those engines cites your docs or comparison page, the user clicks through and the AI client strips the referer, so GA4 buckets the visit as Direct. Across the developer-tools and PLG SaaS sites I have measured in Q1 2026, AI engines accounted for 18 to 34 percent of sessions once the Direct bucket was split by behavioral signal. The honest caveat: this skews high for developer and technical audiences and much lower for non-technical verticals. Measure your own Direct bucket before assuming the rate transfers.

Should a PLG SaaS use Amplitude or Mixpanel for marketing attribution?

No, not as the primary attribution layer. Amplitude and Mixpanel are excellent product-analytics tools for activation, retention cohorts, and in-product funnels, which are central to PLG. They are not marketing-attribution tools and do not natively join channel source to Stripe revenue. The right shape for PLG is two layers: a product-analytics tool (Amplitude, Mixpanel, PostHog) for the activation and retention side of the funnel, and a Stripe-native attribution tool (Attrifast at the SMB end, Dreamdata at the enterprise end) for the channel-to-revenue side. Trying to make a product-analytics tool do channel attribution produces a dashboard that looks comprehensive and does not match Stripe.

When is Dreamdata worth it for a PLG company versus a cheaper tool?

Dreamdata is the right call for PLG companies above roughly $50k MRR with a hybrid PLG-plus-sales motion, account-level buying, and the warehouse infrastructure to feed it. Its entry pricing sits north of $750/mo as of mid-2026, it resolves identity at account scale, and it handles the product-qualified-lead handoff to sales that large PLG companies run. For a bootstrapped or sub-$50k-MRR self-serve PLG SaaS with no sales team, that infrastructure is overkill and the cost-to-decision-value ratio does not pencil. Below $50k MRR a $29/mo Stripe-native tool that does the free-signup-to-paid join and splits out AI channels captures most of the decision value. The honest progression is cheap-and-Stripe-native first, enterprise warehouse later.

What is activation and why does it matter more than signup source in PLG attribution?

Activation is the moment a new user reaches the product's core value — the aha moment — such as sending a first message, inviting a teammate, or shipping a first integration. It matters more than signup source in PLG because activation is the strongest single predictor of paid conversion, far stronger than which channel drove the signup. Two channels can drive identical signup volume and wildly different revenue because one sends users who activate and one sends tire-kickers who never reach value. The PLG attribution model has to track activation as a distinct funnel stage between free signup and paid conversion, otherwise you optimize channels for signups that never monetize.

Can I do PLG attribution without cookies and without a consent banner?

Yes. The minimum cookieless PLG stack is a first-party tracking script that fires on every page and writes a first-party session identifier scoped to your own domain, a server-side session store that captures first-touch source and referer, and a Stripe Checkout metadata field that carries the session identifier into the subscription webhook. None of those three pieces requires a third-party cookie or a consent banner under most jurisdictions, though you should still verify with your own privacy review. First-party server-side attribution also survives Safari ITP and the next round of tracking prevention in a way that GA4 plus a Stripe webhook does not. This is the architecture Attrifast ships.

How is freemium attribution different from free-trial attribution in PLG?

The difference is the conversion window. A free trial has a hard expiry (14 or 30 days), so the paid conversion event is bounded and the attribution window can be short. Freemium has no expiry — a user can stay on the free tier for a year and upgrade whenever a usage limit or feature need finally bites — so the attribution window is effectively unbounded. Freemium attribution therefore requires persisting the original source on the user record permanently and capping the practical attribution window at 90 to 180 days. The freemium model also weakens the signup source signal further, because the gap between discovery and revenue is the longest of any SaaS motion.

What channel benchmarks should a self-serve PLG SaaS expect?

Across the self-serve PLG sites I have measured in 2025 to 2026, free-signup source mix runs roughly 34 percent organic search, 20 percent direct (heavily AI referrals plus brand recall), 12 percent community and referral, 10 percent paid search, 8 percent social, 6 percent content long-tail, and the remainder split across email and partnerships. The more decision-useful number is signup-to-paid rate by source: community and referral signups convert at 22 to 30 percent, organic search at 16 to 24 percent, AI-engine signups at 18 to 26 percent, and paid social at 8 to 14 percent. The pattern holds across PLG verticals — higher-intent discovery channels convert better at the paid stage even when they drive fewer raw signups.

How do I tell which content is driving PLG signups when half my traffic shows as Direct?

Split the Direct bucket by behavioral signal and landing page. A no-referer visit that lands on a deep comparison or docs page from a new visitor, on a page shaped like an AI-citation target (FAQ block, question-shaped headings), is overwhelmingly an AI-engine click rather than true direct. Tag those as suspected-AI, attribute them to the AI channel, and then join the signups they produce to revenue via Stripe. The page-by-revenue list looks completely different once AI is split out of Direct — long-tail docs and comparison pages that GA4 ranked near zero often turn out to be your top signup drivers, which changes content prioritization.

Does product-led growth attribution need multi-touch, or is first-touch enough?

For most self-serve PLG SaaS below $250k MRR, first-touch-on-signup with a last-non-direct overlay is enough and multi-touch is premature. PLG journeys are touch-heavy (a user reads docs, watches a demo, lurks in a community, then signs up), but the variance in multi-touch model outputs at low conversion volume produces channel-budget decisions no better than a clean first-touch model. Above $250k MRR, or earlier for hybrid PLG-plus-sales motions with account-level buying, a position-based or W-shaped model that weights first touch, signup, and paid conversion starts to beat first-touch. The mistake is jumping to multi-touch before you have thousands of conversions a month.

What is a product-qualified lead and how does it fit PLG attribution?

A product-qualified lead (PQL) is a free or trial user whose in-product behavior signals buying readiness — heavy usage, hitting a plan limit, inviting teammates, or activating a paid-tier feature. In PLG attribution the PQL sits between activation and paid conversion as a fourth funnel stage, and it is where hybrid PLG-plus-sales companies hand the user to a human. For attribution this matters because the PQL event is a better optimization target than raw signup volume: channels that produce PQLs are the channels worth funding. Pure self-serve PLG can skip formal PQL scoring; hybrid PLG-plus-sales motions need it, and it requires joining product-analytics behavioral data to the attribution source.

How long does it take to set up PLG attribution from scratch?

With a turnkey Stripe-native tool like Attrifast, 15 to 30 minutes to connect Stripe via OAuth, drop in the tracking script, and map your paid-conversion event. Rolling it yourself is one to three days for a competent full-stack engineer to build the tracking script, first-party session store, Stripe webhook handler, and a basic free-signup-to-paid join, plus another few days to add activation-event tracking and the AI-channel detection layer. Wiring product analytics (Amplitude, Mixpanel, PostHog) for the activation side is a separate one-to-two-day project. Trying to make GA4 plus BigQuery do the whole PLG join is a multi-week project with ongoing maintenance debt.

Why does my Direct bucket show both my discovery and my conversions for PLG?

Because two unrelated things land in Direct for a PLG site, and they get conflated. The first is AI-engine discovery clicks (ChatGPT, Claude, Gemini) whose referer was stripped — that is the top of your funnel hiding in Direct. The second is the in-app billing-page upgrade visits where the paid conversion actually fires — that is the bottom of your funnel hiding in Direct. A naive last-touch read sees both and concludes Direct both discovers and converts your users, which is exactly wrong. The fix is to split Direct by behavioral signal (AI-shaped deep-page entries versus billing-page visits) and route the discovery clicks to the AI channel and the upgrade visits to the original signup source via the Stripe join.

For the general SaaS attribution staging that underlies this PLG-specific piece, see the bootstrapped SaaS marketing attribution playbook. For the AI-engine attribution architecture referenced throughout, the ChatGPT referral analytics guide and track ChatGPT traffic walk the detection layer in depth. For how multi-touch attribution interacts with AI search discovery, see multi-touch attribution for AI search. For the product-analytics-versus-revenue-tracking distinction that decides your two-layer PLG stack, see the product analytics vs revenue tracking comparison. For the product side: the revenue attribution feature page, the Stripe integration page, and the bootstrapped SaaS page walk the Attrifast positioning for self-serve PLG founders.