Privacy & Terms

1. Purposes and event channels

A Posto Event Source may receive optional browser Pixel events, authenticated Conversion API events, supported connected-store events, and events from a trusted mobile measurement partner. Funnel events support the configured measurement, diagnostics, and optimization functions. Only supported final events, including purchase, generate_lead, and app_install, are projected into click attribution and conversion accounting under the applicable event rules.

An integration shall be enabled only for the Advertiser's authorized property and disclosed purposes. The presence of integration code does not mean a feature is active or that a visitor has given consent.

2. Verified domains and confidential credentials

A public Pixel identifier identifies an Event Source and may be used by the Posto Pixel on an exact verified HTTPS domain. It is not a secret or a substitute for domain verification. A Conversion API key is a confidential server credential and shall not be included in browser JavaScript, a tag-manager value exposed to a page, or a mobile binary. Mobile final events shall be transmitted by a trusted backend or authorized measurement partner.

Advertiser shall protect connected-store authorization tokens, use only the scopes and properties it is authorized to connect, rotate compromised credentials, and disable access when authority ends. Authentication verifies a technical submission; it does not establish that its collection or content is lawful.

3. Event fields and connected-store information

Events include a supported name and event time and may include a source URL, stable dedupe_id, Posto click identifier, and permitted event-specific data. Under the current Conversion API purchase schema, a purchase requires a transaction identifier, value, and USD currency; other supported channels shall follow their documented currency and event requirements. A final event requires the Posto click identifier for attribution.

Optional email, phone, client, or user identifiers are accepted only for permitted measurement support. Posto normalizes and SHA-256 hashes accepted values before storing them in event records; transient receipt occurs before hashing. A hash can remain linkable to an individual and is not treated as anonymous merely because plaintext is not retained.

The standalone Pixel may transmit the current page's full URL, including query parameters or a fragment, and use a persistent client identifier and a stored Posto click identifier. Advertiser shall prevent sensitive or unrelated personal information from entering transmitted URLs and shall send only permitted event fields.

Shopify checkout events may include order and checkout identifiers, click and client identifiers, totals, and currency. Shopify order and refund webhooks can transiently deliver broader JSON payloads, including customer details and line items. Posto selects information used for attribution, order status, refund calculations, and reconciliation; refund line items may be read to calculate an amount. Incoming transient payloads are distinct from the selected records retained by Posto.

Advertiser shall not submit names, street addresses, precise location, payment-card data, passwords, authentication secrets, health information, conversation content, or unrelated customer records through measurement fields. Supported store payload handling does not authorize Advertiser to add those details to optional API fields.

4. Deduplication and attribution

Advertiser shall use the same stable dedupe_id when multiple channels or retries report the same real-world action. Posto retains durable deduplication evidence so later retries do not create duplicate results. A Posto click identifier links a supported final event to the authenticated click and associated campaign, advertisement, application, and placement.

An unknown but well-formed click identifier may be recorded as unmatched. A final event lacking a required click identifier is rejected as an integration error. Attribution is limited to the applicable documented window and valid event conditions; submitting an event does not guarantee attribution, payment, or a particular campaign result.

5. Security, browser storage, and privacy choices

Advertiser shall use TLS, secret management, least privilege, stable idempotency, and appropriate key rotation. The Pixel shall operate only on controlled and verified domains after the required notice and subject to applicable consent and opt-out choices. Posto may record authentication and request metadata for abuse prevention and reject an unverified origin, invalid credential, unsafe content, or unsupported schema.

The standalone Pixel does not provide an internal universal consent or Global Privacy Control gate. Advertiser shall implement any required controls over script loading, browser storage, event transmission, withdrawal, and applicable opt-out signals. Its local-storage client identifier has no automatic expiry; the locally stored Posto click identifier has a 30-day validity period. Browser clearing and applicable preference or deletion controls affect local values separately from server retention.

The Shopify web-pixel integration uses Shopify's customer-privacy controls, including marketing-permission handling and clearing stored click information on withdrawal in that integration. This does not govern a separately installed standalone Pixel or relieve Advertiser of its own configuration and privacy duties.

6. Processing roles and individual rights

Advertiser shall establish the lawful basis, give required notices, obtain specific consent where required, ensure event accuracy, and handle rights requests within its responsibilities. Posto processes Customer Personal Data on Advertiser's instructions where the legal processor or service-provider requirements are met and determines certain security, billing-integrity, and legal-compliance purposes independently where permitted. Actual activities and applicable law determine the role; the DPA applies to processing on behalf of Advertiser.

Individuals may contact Advertiser or legal@postoconnect.com to exercise applicable rights. Posto shall assist the responsible business or respond as its role and law require. Neither a tracking identifier nor acceptance of a business agreement waives an individual's privacy rights.

7. Corrections, deletion, and residual records

Advertiser shall correct or reverse final events when an outcome is cancelled, refunded, or otherwise invalid under the applicable event rules. Posto may update attribution and financial reconciliation accordingly while preserving the evidence necessary to explain an adjustment.

Raw advertiser event payloads and diagnostics are scheduled for removal after 30 days, including source URLs, event-row copies of click and deduplication values, optional identifier hashes, and raw or normalized payloads. Event identities, names, times, channels, validation and attribution outcomes, payload hashes, durable deduplication evidence, canonical conversion links, permitted aggregates, and necessary financial or fraud-audit records may remain for their documented operational or legal period. A retained hash or reference is not necessarily anonymous.

A shopper privacy request, store disconnection, deletion of saved catalog content, and account closure are different operations. Disconnecting a store does not necessarily remove products, product sets, images, or other merchant materials already saved in the workspace. Shopper erasure does not require treating merchant-owned campaign assets as shopper data. Required financial and legal records may remain with their use restricted.

Privacy requests and correction assistance may be directed to legal@postoconnect.com. Posto shall apply the process and retention exception appropriate to the requested records; a 30-day server cleanup does not automatically erase browser storage or every related business record.