Consent and privacy. What to mind in an integration.

Consent modes

The mode is chosen per source.

Analytics and marketing consent

• analytics turns on the persistent identity, the retry queue and interaction capture.
• marketing turns on click ids (gclid, fbclid/fbc/fbp, li_fat_id, msclkid, ttclid…) and keeps first and last touch across visits. Without marketing consent click ids are not stored and are sent to no destination.
• Every message carries context.consent: { "analytics": bool, "marketing": bool }. Pass the person’s consent in the same field on events sent from your server.
• With respectGpc: true, the browser’s Global Privacy Control signal turns marketing consent off.

Personal data

• userId must be opaque; never use an e-mail address, a phone number or a national id.
• An e-mail address, phone number, national id, IBAN or card number in an undefined field rejects the message with pii_detected.
• If you must send a personal value (e.g. for ad platform matching), define the property in the event schema with the personal class and the hash action; Postlip Metrics hashes it and never stores the raw value.
• Click and ad ids are exempt from this screening.

Masking on the page

• data-metrics-ignore: the element and its children are never captured (clicks, layout, forms).
• data-metrics-mask or maskSelectors: the label becomes ***.
• Inputs, textareas, selects and contenteditable regions never yield text.
• URLs lose the stripQueryParams entries, sensitive keys (email, token, password…), e-mail- or phone-like values and #…=… fragments; utm_* and click ids stay.

IP addresses and traffic kinds

• No IP address is stored. A server source may pass the end user’s IP in context.ip; it is used for location and internal traffic, then dropped.
• Test (a test key or test: true), internal (an IP range or a cookie flag) and bot traffic are marked apart; screens leave them out by default.

Deletion requests

When your user asks for their data to be erased (KVKK), your product’s server files a deletion request through the Management API. Postlip Metrics carries it out within minutes and keeps a record of the request with the number of rows removed.

• POST /v1/apps/{appId}/privacy/deletion-requests (scope management:write) files the request: subjectKind is the kind of id (user_id, anonymous_id or person_id), subjectValue its value. Put a reference such as a support ticket number in the optional note, never personal data.
• GET /v1/apps/{appId}/privacy/deletion-requests/{requestId} (scope management:read) returns the request’s status (pending, running, completed, failed, cancelled) and, in result, the rows removed per kind of data; nothingFound says no data of that id was found.
• What is removed: the person and every person merged with it; their identities, events, interactions, sessions, account memberships, leads and the Mailing & SMS contact with the same user id (its consent evidence stays by blind index, a keyed hash, as the law requires). Rollups are recomputed from the remaining data; data received after the request has started is not part of it.
• The id’s value is kept only until the request ends; responses show only its last characters (subjectHint).
• A new request for an id that already has an open request returns that request, so resending is safe.

curl -X POST https://api.<domain>/v1/apps/$APP_ID/privacy/deletion-requests \
  -H "Authorization: Bearer $METRICS_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "subjectKind": "user_id",
    "subjectValue": "usr_7c1e",
    "note": "Support ticket 4821"
  }'