---
slug: post-view-messung
title: "How post-view is measured and where it is not"
category: messung
locale: en
updated: 2026-10-14
keywords: ["post-view","view identifier","cookie","coverage","Safari","Firefox","Chrome","third-party cookie","measurement address"]
questions: ["How does a viewable impression without a click get to a purchase in my shop?","How does post-view work technically?","Why is my post-view coverage so low?","Does post-view work in Safari?","What is the view identifier?","Does post-view need a cookie?","What does post-view coverage mean?"]
url: https://bench.metrunio.com/en/help/post-view-messung
---

# How post-view is measured and where it is not

**How does a viewable impression without a click get to a purchase in my shop?**

Through a cookie on the measurement address: pixel and viewability tag set it with consent, the SDK in your shop returns it, and the link is made on the server. That works in Chrome and Edge, not in Safari, Firefox or Brave. How large the linkable share is for you is shown as post-view coverage in the portal.

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. The 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. The 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. The 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. The 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”.

> **Note:** What the browser drops is not replaced. No fingerprint, no redirect through the shop, no probability. The viewable impression stays counted, but without a connection to the purchase.

> **Legal note:** The view identifier is storage on the end device under section 25(1) of the German TDDDG and requires the user’s consent. It belongs in your privacy notice and in your publisher’s. This assessment does not replace legal advice.

## Also asked

- How does post-view work technically?
- Why is my post-view coverage so low?
- Does post-view work in Safari?
- What is the view identifier?
- Does post-view need a cookie?
- What does post-view coverage mean?

## Related

- https://bench.metrunio.com/en/help/impression-pixel
- https://bench.metrunio.com/en/help/viewability-tag
- https://bench.metrunio.com/en/help/click-tracking-url
- https://bench.metrunio.com/en/help/post-view-verstehen
- https://bench.metrunio.com/en/help/keine-post-view-touchpoints
- https://bench.metrunio.com/en/help/meta-google-messen
- https://bench.metrunio.com/en/help/messgrenzen
- https://bench.metrunio.com/en/help/publisher-website