Sellforte Tracking Technology Guidance

Version 2026-09-11

This guidance helps Customers explain and deploy the standard Sellforte Pixel. Actual collection depends on the enabled events and agreed settings. More technical details are available in the Online Service or the Sellforte Support Center.

1 Purpose and consent

The Pixel measures website activity, conversions, marketing effectiveness, and attribution. It does not personalize ads or make automated decisions about individuals. The Customer provides visitor information and obtains required consent before tracking-related collection, device storage or access, or transmission, including buffering in browser memory. A first-party or cookieless design is not automatically exempt.

Connect the website’s consent controls, make refusal and withdrawal as easy as acceptance, and stop tracking and clear pending events and the analytics cookie on withdrawal. Test consent behavior before launch. Do not use the technology to identify, profile, or target children; contact Sellforte before deploying it on child-directed properties.

Custom consent platform. Connect its consent-ready and consent-change callbacks to window.sfTrackerConsent(analyticsConsentFromCmp === true); when using the supported queued consent integration. Pass true for analytics consent and false for denial or withdrawal. Use the consent platform’s documented API, not an inferred cookie value. The queue must be available before callbacks run; use the configuration supplied through the Sellforte platform.

For an existing programmatic integration after the tracker is ready, use window.SFTracker.instance.consent({ granted: true }); to grant consent and window.SFTracker.instance.consent({ granted: false }); to deny or withdraw it. Forward both the stored decision on page load and later changes.

Cookiebot. Select Cookiebot as the consent provider in the Sellforte platform. The integration reads Cookiebot.consent.statistics and follows Cookiebot’s consent-ready, accept, and decline events automatically. An initial false value remains pending until Cookiebot confirms that the visitor has responded; a confirmed refusal clears pending events.

HubSpot. Enable an opt-in banner with consent by category for each tracked domain and select HubSpot as the consent provider. The integration reads consent.categories.analytics from HubSpot’s consent callbacks. Advertisement or Functionality consent alone does not grant analytics consent. A startup false value before a recorded decision remains pending; a persisted Analytics refusal clears pending events.

Google Tag Manager and Shopify. These are deployment platforms, not the source of the analytics-consent decision. Connect the consent provider actually used on the website or storefront through a supported integration above. A fired tag does not prove consent or transmission; verify that no request reaches /api/tracker/collect before required analytics consent. A Shopify theme integration does not automatically cover checkout.

Tracker behavior. In consent-required mode, the delivery gate waits for analytics consent before sending tracking events. Denial discards pending events; withdrawal stops later delivery and expires the analytics cookie. The documented integration can retain landing context and pending events in browser memory before a decision. Where consent is required for that collection or storage, block it too; withholding network requests alone is insufficient. If the selected installation cannot do this, keep the affected tracking blocked and contact Sellforte. A “consent not required” setting may be used only where a lawful exemption actually applies.

2 Details for your visitor notice

Data. Configured page, session, campaign, and limited browser data, including URLs, referrers, and pseudonymous identifiers. Optional website events can include product views, cart activity, and purchases with an order identifier, value, and currency. Send only agreed fields; exclude unnecessary personal information, credentials, and unrestricted form content. Linkable identifiers remain Personal Data.

Cookie. The standard first-party __sftr_cid analytics cookie contains a random identifier, covers the registered domain and its subdomains, and has a 365-day configured lifetime. It is set after analytics consent and expired on withdrawal. Disclose any agreed different setting.

Retention. Tracking data is retained during the customer agreement and then returned or deleted under DPA Section 11 and ToS Section 17.6, including their retrieval and backup provisions. Earlier lawful deletion instructions and shorter mandatory deadlines prevail. Standard operational records expire after 30 days for deduplication, 180 days for ingest audits, and 365 days for data-protection actions.

Recipients and location. Data goes to Sellforte’s production collector, hosted on AWS in the EU unless another location is agreed. DPA Annex C identifies subprocessors and international access; Annex D covers transfer safeguards. Your notice must explain the actual purposes, lawful basis, retention, recipients, consent choices, rights, and contact details.

3 Processing roles

Sellforte normally processes tracking data for the Customer under the DPA. Where the Parties jointly determine collection and transmission, DPA Section 1.2 allocates their responsibilities: the Customer handles deployment, visitor notices, consent, and initial rights requests; Sellforte handles its technology, security, and consent signals. Explain that arrangement in the visitor notice where it applies. Visitors may exercise rights against either Party. Deployment alone does not establish joint controllership.

4 Event configuration and validation

Register all relevant domains and subdomains with Sellforte; unregistered hosts are rejected and may break session and attribution continuity.

Base page and session signals follow the configuration. Supply agreed business events explicitly through HTML event attributes, the JavaScript API, or an agreed server integration. Examples include product_view, add_to_cart, begin_checkout, and purchase. Record a conversion only after confirmed success, with a stable approved identifier to avoid duplicates. Known-user identity, if enabled, requires the agreed permissions and consent and must be cleared on logout.

Test a fresh visit, consent grant, refusal and withdrawal, cookie behavior, tracked requests and browser storage, the agreed event fields, and any login/logout flow. The extranet website check inspects published HTML and may miss tags injected by a tag manager. Browser validation checks actual runtime behavior when enabled. Revalidate after configuration changes; an HTML pass alone does not verify consent compliance.

Back to document navigation