Skip to main content

Implement website and application tracking

Choose where your events are sent​

Creating a Platform project does not install tracking. Your website, tag manager or backend must create and send events. In Tracking setup, select the location, method and ingestion key for the selected environment.

IntegrationWhere it runsKeyInstallation
Direct JavaScriptWebsite visitor's browserBrowser keyInstall the generated runtime snippet on your website
Web-GTMWeb tag manager containerBrowser keyInstall the generated Custom HTML tag
Adobe LaunchWebsite's tag libraryBrowser keyAdd the generated Core Custom Code action
JSON Server TagServer-GTM containerServer keyConfigure the outgoing HTTP request in the tag
HTTP integrationYour backend or relayServer keySend JSON to the ingestion endpoint

For a backend integration, continue with the HTTP API guide. For a browser integration, follow the steps below. An administrator needs to create or select the key. The key determines the organization, project and environment.

1. Configure a browser key and allowed origins​

Create a browser key in Ingestion keys. Add each website origin that sends events, for example https://www.example.com and https://shop.example.com. Origins include the scheme, hostname and any non-default port. Do not include a path or a wildcard. Use HTTPS. HTTP is supported for local development on localhost or loopback addresses.

A browser key is visible to website visitors. Never use a private server key in browser JavaScript, Web-GTM or Adobe Launch. Origin restrictions control browser access. They do not make the browser key a secret or prevent a non-browser client from imitating a request.

Use separate environments and keys for testing and production. When testing on http://localhost:8080, allow that exact origin in the test environment.

2. Install the generated runtime​

In Tracking setup, choose your browser method and key, then complete the runtime settings. Use the generated snippet for your environment instead of copying another project's key or schema version.

Library HostingWhat to deploy
Self-hostingDownload the minified JavaScript, upload it to your website and enter its Library URL
InlineCopy the generated snippet with the included library
jsDelivrSelect a fixed release in Library Version and use the generated Library URL

Allow the selected library and ingestion endpoint in your website's Content Security Policy where applicable. For Web-GTM, use the generated Custom HTML variant. For Adobe Launch, use the generated Custom Code without surrounding HTML script tags. For direct JavaScript, install the initialization before invoking your event sender. The generated sender waits for the library to load before sending events.

Define triggers deliberately. Installing the runtime does not define which business actions should create events. For a single-page application, trigger page events on relevant route changes and check that navigation does not send the same event twice.

The setup offers browser-generated device IDs, IDs supplied by your own integration, and a mode without a browser-generated device ID. Session-ID generation is optional. If you enable it, also configure Platform to use supplied sessions. Otherwise, reporting can derive sessions from identity and inactivity.

For generated IDs, choose Cookie or LocalStorage under Shared ID storage. LocalStorage is specific to one origin. For shared cookies across subdomains, use consistent storage settings and a compatible cookie domain. Different main domains do not share these IDs. Keep test and production storage separate.

When the generated snippet includes browser identity management, connect your consent manager to the generated window.setTrackingIdentityConsent function:

// Call from your consent integration when identity storage is allowed.
window.setTrackingIdentityConsent(true)

// Call when that permission is withdrawn.
window.setTrackingIdentityConsent(false)

This controls runtime identity storage and enrichment. It does not stop event transmission or cancel requests already in progress. Gate event creation and sending separately in your consent integration. Destination consent filtering is another separate check. It uses the boolean fields mapped in your published schema.

If your installation offers daily IDs without browser storage, follow its setup instructions for X-DDA-Identity-Mode: daily and the required schema mappings. Do not assume that selecting the option alone enables it. Confirm the environment's tracking diagnostics with fresh events.

4. Send your own events​

After installing the generated snippet, invoke its sender from your chosen trigger:

window.sendTrackingEvent({
event: {name: 'button_click'},
button: {id: 'start_trial'}
}).catch(function (error) {
console.error('Tracking request failed', error)
})

This is a sample event structure, not a universal schema. Map event.name to Event name and include button.id as a string in the button_click event schema. Add any other fields your schema requires. A caught transport error is only one failure signal. Also inspect the ingestion response and individual event results.

Before the first schema is published, send representative samples without the schema version header. Review discovery, map the fields and publish the schema. Then use Update tracking to add the exact published version to the existing implementation. Publish the changed website code, tag container or Launch library.

5. Verify the complete path​

Trigger one new event in the test environment. Check the outgoing JSON and response in browser developer tools or the tag manager's preview. Confirm that the selected key, origin and schema version belong together.

sampled_for_schema_discovery means setup discovery. validated_only means checking without storage. queued means accepted for processing, not delivered to the warehouse. Complete the destination setup, trigger fresh events and verify them in the warehouse before building reports.