How post-view is measured and where it is not

A click carries its identifier onto the landing page. A viewable impression carries no identifier along, unless the browser does. The only thing a browser carries from one site to another without a fingerprint and without circumventing its own protection is a cookie of the address contacted on both sides. That address is your measurement address: your own measurement domain, or the shared one if you have not set one up.

The path in four steps

1. 01The impression pixel is loaded with the publisher’s consent (c=1) and sets the view identifier: a cookie called metrunio_view, valid for 30 days, for the measurement address only.
2. 02The viewability tag reports the impression as viewable and, while doing so, measures whether the browser returns the view identifier. This yes or no is the basis of coverage.
3. 03The later visit to your shop: with marketing consent the SDK sends to the same measurement address, and the browser attaches the cookie if it kept it.
4. 04The worker joins both sides through the view identifier, deterministically, as with a click identifier. If the viewable impression lies within the view window, it receives a share in the model with post-view, from the Pro plan.

If the person withdraws marketing consent in the shop, the collector removes the cookie, and the viewable impressions linked to this browser are deleted (see the article on withdrawal).

Where it works

• Display and programmatic with your own tags: in Chrome and Edge with default settings, on desktop as on Android.
• Ads on your own pages (onsite teasers, homepage banners): the SDK runs there, and the link is made through its first-party identifier, without any third-party cookie.
• Only with consent on both sides: at the publisher, whose consent tool passes it to the ad server and on to the pixel, and in your shop.
• Only with the same measurement address in pixel, tag and embed code. If you set up your own measurement domain, replace all three. The portal generates them to match.

Where it does not

• Safari and Brave drop the cookie on the publisher page because it is a third-party cookie there; Firefox puts it into a partition of the publisher page that never reaches the shop. That also holds with your own measurement domain: to the publisher it is still a third party. The same applies to Chrome in incognito mode and to users who have blocked third-party cookies.
• Inside the closed feeds of Meta, Google and TikTok: no platform allows a foreign tag there. The click is measured, the viewable impression is not.
• Newsletters: an open is a loaded image, not a viewable impression. Mail clients load images without a reader. It is recorded as email_open and never receives a share.
• A platform’s view-through numbers (DV360, CM360, Meta) are aggregated and not deterministic. They are never reinterpreted as touchpoints of our own.

Coverage

Next to the post-view share the portal shows post-view coverage, by channel and by browser family, in two numbers. “Proven”: the view identifier came back from the other context, issued in the shop and returned on the publisher page or the other way round; this browser lets the viewable impression and the purchase be linked. “Returned”: some view identifier came back at the viewability tag. Firefox does that too, from a partition of the publisher page that never reaches the shop. The first number is the lower bound, the second the upper; both are measured, not assumed. A post-view share of three per cent means something different at twelve per cent coverage than at ninety. Without a view identifier a viewable impression receives no share; for the unlinkable part, conversions remain “unattributed”.