Going Live

This guide covers what you need to do to move from local development to a production deployment serving real traffic.

1. Set Up Your Data Collection Domain

In production, events should be sent to a subdomain you own (e.g. data.yourdomain.com) rather than localhost. This is important for:

• First-party data collection — the browser sees your subdomain, not a third-party domain
• Durable cookies — first-party cookies are not affected by third-party tracking restrictions in modern browsers
• Ad blocker resilience — first-party traffic is not blocked

DNS Configuration

Create a DNS record pointing your data collection subdomain at your Signal deployment. Your account team will provide the exact record type and target during onboarding — the goal is to have your subdomain resolve directly to your Signal instance so that all requests and any cookies are treated as first-party.

data.yourdomain.com  →  (your Signal deployment)

2. Configure the JS Collector for Production

Build the production collector from your Collector tab in the Management UI — the JS Builder bakes the pipeline key, endpoint and any consent / identity-sync config into the script body. Update the install on your site to point to the production-built script:

<script src="https://data.yourdomain.com/df_your_pipeline.js" async></script>

Make sure:

• The endpoint uses https:// (SSL is required in production)
• The script you upload was built from your production pipeline (the pipeline key is baked into the JS, not passed at runtime)
• The snippet is loaded on every page of your site
• Cache headers on your CDN match what you set in the JS Builder (Cache-Control max-age) — re-purge the CDN after each rebuild

3. Verify Production Events

Before sending real traffic:

1. Open the Real-time Debugger in the Management UI.
2. Visit your production site in a browser and trigger some test events.
3. Verify that events appear in the debugger and show the correct data.
4. Check the delivery status — events should show as successfully delivered to each vendor.

Checking Vendor-Side

After verifying events flow through Signal, confirm they arrive at each vendor:

4. Configure the organisation processing

Before going live with real traffic, review and configure your organisation processing settings under Settings in the Management UI:

Consent Enforcement

If your site uses a consent management platform (OneTrust, Cookiebot, Cookie Information, etc.), Signal reads the standard Google Consent Mode v2 signals from the page and gates per-vendor delivery on them.

To configure:

1. In the Management UI, go to Settings > Consent.
2. Set the Default consent state for any visitor whose consent has not yet been recorded (typically “denied” for marketing-related vendors).
3. For each integration in your Integration Library, set the Required consent categories (e.g. Meta CAPI requires ad_storage and ad_user_data; GA4 with consent mode requires analytics_storage).
4. Verify your consent platform is exposing the standard dataLayer consent events. See the Consent Management page for the supported integrations.

Events that don’t meet a vendor’s required consent are dropped at the organisation processing before delivery — no per-vendor scripting needed.

Bot Filtering

Enable bot filtering to remove non-human traffic before it reaches your vendors and inflates your reporting.

To configure:

1. In the Management UI, go to Settings > Bot Filtering.
2. Toggle Enable bot filtering on. Bot filtering is enabled by default for new pipelines.
3. Choose your sensitivity profile (start with the default “Standard” — see Processing for guidance on tuning).
4. Optionally add user-agent or IP allowlist entries for your own monitoring tools (Pingdom, Datadog Synthetics, internal QA infrastructure).
5. Enable Log blocked events if you want to inspect what’s being filtered — events are retained for analysis.

Verify by visiting Observe > Bot Traffic to see the bot rate and top filtered event names.

PII Handling

Configure how personally identifiable information is handled before delivery:

• Pass through — send PII as-is (when permitted by the vendor and your privacy policy)
• Hash — SHA-256 hash PII before delivery (required by Meta CAPI, Google Ads Enhanced Conversions, etc.)
• Redact — replace PII with a placeholder
• Drop — remove the field entirely

5. Go Live Checklist

Before removing your existing vendor tags and relying solely on Datafly Signal:

• Data collection domain is configured (DNS + SSL) and resolves to your Signal deployment
• Datafly.js snippet is on every page with the correct pipeline key and endpoint
• All required integrations are installed and configured
• Events are appearing in the Real-time Debugger
• Events are arriving at each vendor destination (verified vendor-side)
• Consent enforcement is configured (if applicable)
• Bot filtering is enabled
• PII handling is configured
• Team members have been invited with appropriate roles

6. Remove Legacy Vendor Tags

Once you’re confident events are flowing correctly through Datafly Signal, remove the individual vendor JavaScript tags from your site:

• Google Analytics (gtag.js or analytics.js)
• Meta Pixel (fbevents.js)
• TikTok Pixel
• Any other vendor-specific scripts

Datafly Signal now handles all event collection and delivery server-to-server.

Next Steps

• Security — Encryption, authentication, RBAC, and consent enforcement
• Processing — Fine-tune processing controls and per-vendor transformation
• Integrations — Browse the full Integration Library for 150+ vendor destinations