- Ya
- 24 Agosti 2026, 23:47 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 03467c9
A member checking that their own tracking link works is the most common first visit any code ever gets, and it is worse than useless: it inflates the number they are measured on, it is indistinguishable from a real prospect in the visitor drawer, and it leaves them holding a permanent visitor cookie so every later visit counts again. A code showing three visits, all of them the person who minted it, is a payment record with a lie in it. This site is the only origin that can answer the question — it has no session and no member, and the internal console cannot set a cookie on www.<apex> from internal.<apex>. What crosses that gap is a link: arriving with ?mrt_self=1 mints the exclusion, and from then on the browser is excluded on every visit whether or not the parameter is there. The internal Tracking Codes tab grows the control that produces that link. Not minting is not enough, so an excluded visit DELETES the visitor and source cookies too. A member who previewed their link before this shipped, or who opted out on a browser already counted, is still carrying a GUID — and the beacon fires for anyone who has one. Without the delete the opt-out would only ever have worked for people who did not need it. The exclusion is deliberately NOT in TRACKING_COOKIES: that set is what the cookie policy's delete control clears, and sweeping an opt-OUT away with the identifiers would silently re-enrol the one visitor who asked not to be counted — on the control most likely to be pressed by exactly that person. check-discount-cookie grows from 50 checks to 72, covering the value matching, the parameter spellings, the delete-set exclusion, and the two source invariants (middleware must delete the identity, the beacon must bail locally because middleware runs on document requests while the beacon runs on every client-side navigation).