Collection modes, consent, retention, and the settings that change what you are processing.
| cookieless | Nothing stored on the device. Visitor ids rotate daily and cannot be followed across days. |
| cookie | A first-party cookie for 12 months. True cross-day visitors, and in most EU configurations this needs consent. |
| identified | Cookieless collection plus identify(). Real retention on signed-in users without a cookie. |
Worth knowing. In cookieless mode, multi-day retention for anonymous visitors is not merely inaccurate, it is impossible. The retention screen says so instead of rendering a grid of zeroes.
Three modes. not_required collects immediately. required buffers events in memory until consent('granted'), and discards them on denial. required_strict does not even buffer.
Global Privacy Control and Do Not Track are honoured by default. A visitor sending either is not counted at all, and only an aggregate counter moves, because keeping a per-visitor record of who refused would be its own processing problem.
mw.consent("granted"); // release the buffer
mw.consent("denied"); // discard it, collect nothing furtherSet per project from 3 to 36 months. A nightly job drops expired data and writes a receipt with row counts before and after, verified by re-counting. The Privacy screen shows the real cutoff date computed from your data, not a policy statement.
Export or erase everything held for a visitor hash or a user id from the Privacy screen. Deletion re-counts afterwards and fails loudly if anything survived, then issues a receipt you can hand to whoever asked.
Access to that console is a separate grant. No role includes it, including Owner, because exporting everything held about a person is a deliberate act somebody should have been given.