Finding the True Owner of Branded-Search Conversions with GA4 Attribution, When PPL and Viral Reach Get Harvested as Search

For: marketing practitioners, data analysts  ·  Format: explainer guide  ·  2026-07-11

We Couldn't Say Where Half of Our Conversions Came From

Every month-end report hit the same wall. Roughly half of consultation conversions were branded search, calls that came in from people directly searching the company name or service name, and this path carried no channel tag at all.

Branded search isn't the name of an ad channel, it describes the behavior of "searching a company name directly." So what came before that behavior? Did they see an ad, or hear it from a friend? Click data doesn't say.

Looking for an answer, I once asked the call center staff to add one line every time they picked up: just note "where did you hear about us."

The results fell short. Slipping in a question that wasn't part of the normal call flow felt awkward, so the records were spotty, and a lot of the answers, things like "I just searched for it," couldn't pin down a channel anyway. Filling the gap by asking people directly didn't hold up for long, at least in this situation.

This post tries to answer two questions. Can that lump sum even be split by source in the first place? And if it can't, what can we do instead?

Click Data Simply Has No Trace of PPL to Begin With

PPL (product placement, an ad that appears naturally inside TV or YouTube content) leaves no record in any browser anywhere. Watching happens off-screen, and the web only enters the picture once someone taps the search bar afterward.

GA4 (Google's free web and app analytics tool) only logs events that happen in a browser or app, so viewing in front of a TV is structurally invisible. This invisible upstream stretch is often called the dark funnel (the front part of the marketing funnel that data simply can't catch).

And that's where a common misjudgment creeps in. Someone checks GA4, sees branded search as the first-touch channel, and concludes that branded search itself is a high-performing channel, then shifts budget toward it. But branded search isn't the source, it's just the door where demand that's already been created gets harvested. What put someone in front of that door might have been PPL or a blog going viral, but the credit swings back toward the door.

TV and video viewing happens outside the browser and stays in the dark funnel, and branded search is just the door that demand walks through.

The Fork: Stitch People Together, or Measure the Flow

This is where the path splits, one side stitches individual people together, the other measures aggregate flow. The two paths answer different questions.

Individual tracking, the ledger, answers "which path did this specific person take," but without login or a phone number, coverage stays low. Aggregate allocation, the estimate, answers "how much did this channel contribute overall." It doesn't need to stitch individuals together, but in exchange it moves from certainty to plausibility.

This isn't really a pick-one-or-the-other problem. First split the questions you can answer from the ones you can't, and approach each with a different tool. The rest of this post follows that fork down both branches.

The path that stitches people together and the path that measures flow are, from the outset, answering different questions.

The Ladder for Stitching People Together Has Three Rungs

Rung one is the browser key. GA4 issues a client_id stored as a cookie in the browser, which persists within the same browser but can't cross devices, and browsers like Safari that have built-in tracking prevention cut this key's lifespan short.

Rung two is storage. This covers a first-touch slot (the path a visitor arrived through the very first time) frozen into the browser's local storage (localStorage), and a last-touch slot that keeps getting overwritten with the most recent arrival info. These slots typically get a validity window somewhere between 30 and 90 days, depending on the design.

Rung three is the person key. A phone number stored not in plain text but as a hash (a value transformed one-way so the original can't be recovered), or a login ID (user_id), ties a person together, and the moment someone logs in, the several browser keys that had been operating separately all get organized under one person.

There's an honest limitation here too. Without a login, there's no way to recover a touch that happened on a different device before conversion, and that's less a shortfall in technology than a structural limit. The person key needs to already be planted on that other device for the journey to connect, and it can't be planted before login happens, so there's no way around it.

Climb higher and certainty increases, but coverage narrows the higher you go.

Three Free GA4 Features Reveal the Front Half of the Journey

Do you really need an expensive CDP (customer data platform) or a dedicated attribution tool? GA4's built-in features alone can get you surprisingly far. Let's walk through three, in order.

First, the free-form report under the Explore menu. Put first user source/medium on rows and session source/medium on columns, cross-tab them, and it becomes visible that the channel where someone was first discovered and the channel that actually drove the sign-up are often different. If the channel that got noticed first and the channel that got the final push are different, some other force stepped in somewhere in between.

Second, the paths report inside the Attribution menu under Advertising. It used to be called the conversion paths report and is now called the key event attribution paths report, but the core function, showing the order of channels a conversion passed through, hasn't changed. Even if branded search is the last click, if there was another touchpoint before it, that shows up in the path too.

Third, exporting to BigQuery (Google's data warehouse, free daily raw event export if you're on a GA4 standard property). Since GA4's own unique identifier (user_pseudo_id) is assigned per browser even without login, you can build your own source sequence directly, going beyond whatever tables the UI has pre-built and reconstructing the journey from whatever angle you actually need.

The menu paths described here reflect only what's generally known. Google changes its screen layouts and feature names often (even its own official support docs show recently renamed items), so it's safer to confirm the exact button names and locations directly in the GA4 interface.

With no extra tools at all, GA4's built-in features alone reveal a good deal of the journey's front half.

The Flow-Measuring Side: Splitting Credit by How Much Search Volume Moved

If you can't stitch individuals together, aggregation is what's left. It's a method of taking however much search volume spiked above the usual level, the excess (lift, the part that pops above the baseline of normal activity), and splitting that credit among the signals likely to have caused it.

The delay where an ad's effect doesn't fully land the same day but shows up over several days is called adstock, and the larger the decay rate lambda, the longer the delay stretches. In a live delay model run across 16 channels together, at lambda=0.75 it took 7 days after exposure for 90% of the cumulative effect to show up.

What happens if you only look at same-day views against same-day performance? All of the delayed portion leaks into the baseline, meaning the demand that would have existed anyway, and a channel's real contribution gets measured smaller than it actually is. In that same 16-channel analysis, the baseline came out to 60% without accounting for delay, but dropped to 26% once delay was factored in, and R-squared (the coefficient of determination, showing how well the model explains the data) jumped from 0.30 to 0.74. That's how much difference leaving out one delay factor made versus filling it in, not something to take lightly.

In a separate project, there was an actual reversal. The correlation between PPL view count and branded-search volume was a weak 0.15, and looking at view count alone nearly led to the conclusion that "PPL isn't doing much." But swap view count for spend intensity, how much was actually being spent during that period, and the correlation jumped to 0.44. How hard the campaign was being run tracked search volume far better than raw exposure volume did (509-day analysis, January 2025 through May 2026).

At the same time, conversions were tightly bound up with ad spend itself, the correlation between total ad spend and total conversions was 0.666, the strongest of the three metrics. The ad budget that increased during that period got tangled up with the PPL effect, making it structurally difficult to isolate PPL's standalone effect from observational data alone.

So search volume shouldn't be tracked on its own, it needs to be stacked alongside an event calendar (air dates, publish dates, campaign on/off records) and channel-by-channel ad spend. Only by overlaying these three time series can you even tell, at minimum, the direction of whether a given day's search-volume rise came from an airing or from an ad-spend increase. Splitting branded-search volume by mobile versus PC adds one more layer of clue here too, since searches right after watching a video tend to skew mobile, so a spike in mobile share at a given point can be used as a fingerprint of PPL.

This kind of allocation is an estimate to the very end. It isn't meant to be a model that produces a precise, per-channel correct answer, it's meant to be used as a tool for gauging direction and rank order. Knowing when to give up on precise estimation, isn't that its own kind of skill?

View count alone correlated weakly at 0.15, but spend intensity reached 0.44, and the ad spend-to-conversion correlation was strongest of all at 0.666 (509-day analysis).

Keep Two Ledgers, Don't Merge Them, Compare Them

The moment you force the ledger (fact, a certain individual-level record) and the estimate (allocation, an aggregate-level split) into one table, the analysis stalls. Merging them brings a real fear along with it: double counting, tallying the same result twice.

The ledger never allocates anything. It only counts what's clearly tagged, so there's never any overlap with the estimate, and the estimate only applies to whatever lump the ledger couldn't fill in. As long as the two are never added together, only placed side by side, the risk of counting the same result twice never even arises.

The validation sample refers to responses gathered from a subset, like a single short survey question after a consultation call, or a dropdown option on a web form. It isn't a number to add into the performance total, it's only used as a yardstick to check whether the ratio the estimate ledger produced is accurate.

If the question is "where did this person come from," look at the ledger. If the question is "how much did this channel earn overall," look at the estimate. If the two answers diverge sharply, isn't that a signal to gather more validation samples, or design an experiment?

Once a month is plenty as a working routine, lay the ledger's channel ratio, the estimate ledger's allocation ratio, and the validation sample's ratio side by side. If the three roughly agree, keep running things as they are, and whichever channel stands out as off becomes next month's thing to check.

The ledger, the estimate, and the validation sample are three books you place side by side and compare, never merge.

The Big Picture: Five Layers from Supply to Confirmed Revenue

Put all the pieces together so far on one page and it looks like this. At the top is supply, the source signals, PPL view counts, blog exposure, channel-by-channel ad spend, and the event calendar, the signals scattered out into the world. After a few days of delay, this moves into the second layer, demand expression, where branded-search volume split by mobile/PC and direct traffic take their place.

The third layer is acquisition, the session source and first-user source that GA4 captures. The fourth layer is the conversion ledger, tagged web leads, calls (via tracking number), and sign-ups (via user_id), and the fifth and final layer is confirmation, the place where activation and revenue are actually joined together.

This picture reads in two directions. Read top to bottom and it's the ledger, tagged conversions flow down through the layers to become a per-channel floor. Read left to right and it's the estimate, time series flow sideways, allocating untagged lumps back toward the source signals.

Map this onto your own organization and the gaps should become visible. Of these five layers, which ones are already being captured, and which are still empty? Most often, acquisition and the conversion ledger are already in place, while the habit of stacking supply signals as a time series, or the storage side like a first-touch slot, is the part that's missing.

What to Start Stacking Tomorrow

That's the story. Now hold it up against your own five layers. Check which layer is empty first, and fill that one in first.

If you only take one thing away, let it be this.

Branded search is a door, not a source, don't merge the ledger and the estimate, compare them.

There are companion pieces that unpack this framework from the ground up. For the dark funnel concept, see the dark funnel tracking guide; for attribution models, see GA4 attribution models explained; and for a five-layer self-assessment workbook, see the marketing measurement five-layers audit.

Sources

• GA4 free-form Explore report: Google Analytics Help, Free-form exploration
• GA4 key event attribution paths report: Google Analytics Help, Key event attribution paths report
• GA4 free BigQuery export: Google Analytics Help, Set up BigQuery Export
• Attribution methodology (adstock, triangulation): internal analysis, unpublished
• PPL halo-effect correlation and lag analysis (0.15/0.44/0.666): internal analysis, unpublished

Figures like the consultation ratio and correlation coefficients come from actual analysis, but the company name has not been disclosed. All search-volume allocation (lift) figures are estimates, and the adstock decay parameter is a measured estimate from one specific project, so it won't transfer directly to a different industry or channel mix.