What happens if clickid gets lost during a PWA install?

The conversion can still reach the affiliate program, but the postback won't be able to tie back to the original click and campaign — ROI reporting ends up incomplete right at that point.

Why doesn't a regular link with a parameter work after a PWA is installed?

Because the installed app launches as its own entry point rather than through the original URL with query parameters — without saving clickid before that point, there's simply nowhere for the app to get it from on a later open.

Does a buyer need to code clickid persistence themselves in APEX?

No — APEX captures and stores clickid on first visit and attaches it to events inside the installed PWA automatically.

Can other parameters travel alongside clickid, like sub IDs?

Yes — clickid is usually passed together with extra sub-parameters (geo, creative, placement), and that whole set needs to persist the same way clickid does for analytics to stay granular.

How do you verify clickid reaches the postback without loss?

The simplest way is a test click with a known clickid, followed by a conversion inside the PWA, then checking that the same clickid shows up on the postback received by the tracker or affiliate program.

Passing clickid Through a PWA Without Losing Attribution

Passing clickid through a PWA is where attribution most often breaks: the parameter is easiest to lose exactly at the moment a user leaves the browser for a standalone installed app. Here's where clickid typically drops out and how to carry it through so a postback always knows which click to credit.

What clickid Is and Why Attribution Falls Apart Without It

A clickid is a unique identifier a tracker or ad platform assigns to a specific click, so a conversion can later be tied back to it through a postback. Without it, an affiliate program can technically confirm that a conversion happened, but it can't say which click, campaign, or ad it came from — which makes honest ROI reporting by creative or audience impossible.

The Normal Path: From Click to Landing Page

In a classic non-PWA setup, clickid rides along as a URL query parameter — a user clicks an ad, lands on the tracker, which redirects to the landing page while keeping the parameter in the address bar. As long as the user stays in one browser tab, the parameter just travels through the redirect chain with no extra work needed.

Where It Gets Complicated With a PWA Install

The trouble starts at install: the user adds the PWA to their home screen, and the next time they open it, it launches as a standalone app rather than through the original ad link — meaning no query parameters in a URL at all. If clickid wasn't saved somewhere before that point, the app has no way to know which click that specific user came from on the next open.

How clickid Gets Preserved on the PWA Side

The fix is saving clickid to the device at first visit or install — in localStorage or the service worker's IndexedDB, for instance — while the parameter is still available in the URL, then attaching it to every in-app event afterward: open, registration, deposit. That's how the parameter survives the jump from a browser tab's context into an installed app's context with no address bar at all.

The Path Back: From an In-App Event to a Postback

When a target action happens inside the PWA — registering with the offer, a deposit — that event needs to carry the saved clickid along with it, either through a direct call to a postback URL with that parameter, or by handing it to the affiliate program at registration so it fires its own S2S postback tied to the same clickid. If the parameter gets dropped or mangled at this step — truncated, or mixed up with a different sub ID — the conversion still arrives, but it never matches back to the original click.

How This Works Inside APEX

In APEX, carrying clickid through install and the PWA's entire lifecycle is built into the platform: the parameter gets captured on first visit, survives the install, and attaches to in-app events automatically, with no manual persistence logic for the buyer to build. That directly affects S2S postback accuracy — including a Keitaro↔FB CAPI setup — because the tracker receives the conversion tagged with the same clickid that was on the original click.

FAQ

What happens if clickid gets lost during a PWA install?: The conversion can still reach the affiliate program, but the postback won't be able to tie back to the original click and campaign — ROI reporting ends up incomplete right at that point.
Why doesn't a regular link with a parameter work after a PWA is installed?: Because the installed app launches as its own entry point rather than through the original URL with query parameters — without saving clickid before that point, there's simply nowhere for the app to get it from on a later open.
Does a buyer need to code clickid persistence themselves in APEX?: No — APEX captures and stores clickid on first visit and attaches it to events inside the installed PWA automatically.
Can other parameters travel alongside clickid, like sub IDs?: Yes — clickid is usually passed together with extra sub-parameters (geo, creative, placement), and that whole set needs to persist the same way clickid does for analytics to stay granular.
How do you verify clickid reaches the postback without loss?: The simplest way is a test click with a known clickid, followed by a conversion inside the PWA, then checking that the same clickid shows up on the postback received by the tracker or affiliate program.

Build your PWA in APEX in minutes

Cloaking, anti-bot, push, split tests and your own domains — in one service.

Get started free