Providers

Fourteen providers, each validated against its own ID format so a mistyped container id is caught in the console rather than discovered as a silent gap in reporting weeks later.

Where each id lives

Every one of these is a different console, and not knowing where the id is kept is the most common reason a tag never gets added. The console shows the same line under the field as you type.

This table is generated from the same catalogue the console reads, so the two cannot disagree. Vendors do reorganise their menus - if a path here is wrong, it is wrong in one place.

PostHog also asks for a Region: us.i.posthog.com or eu.i.posthog.com, matching the cloud your project was created in. Only those two are accepted, so a self-hosted PostHog cannot be pointed at from here.

Conversion labels

Google Ads, X and LinkedIn do not take an event name. They take an id you create in the ad platform, one per action you want to count. The console asks for those on the four that matter commercially - sign-up, trial, purchase and subscription - and sends what you filled in.

Leaving one blank is a supported choice: that event is not reported to that network. It is worth knowing because the failure is otherwise invisible - an unreported conversion looks exactly like nobody converting.

Google Tag Manager

GTM is one provider among the fourteen, not a thing BuildBase replaces. Paste one container ID and every event - ours and yours - arrives on the data layer as a trigger, with your triggers, variables and versioning staying where they already are.

A provider we do not have

Two escape hatches, in order of preference.

A script URL. Anything configured entirely through data- attributes - Fathom, Umami, Simple Analytics, Endorsely - can be added as an external script with its attributes. It installs, and it appears in the consent manifest if you name the vendor.

https://cdn.usefathom.com/script.js   data-site=ABCDEF

Your own repo. You own your codebase and can add any <script> you like. BuildBase stores no inline JavaScript on your behalf, deliberately: a console that stored executable code would be a stored-XSS surface spanning every customer's origin, and it would duplicate something you can already do.

Content-Security-Policy

If your app sets a CSP - and it should - the tags need to be allowed, or they are blocked with no error anywhere a developer will see it.

script-src  'self' https://analytics.ahrefs.com https://analytics.tiktok.com
            https://bat.bing.com https://connect.facebook.net
            https://googleads.g.doubleclick.net https://plausible.io
            https://scripts.clarity.ms https://snap.licdn.com
            https://static.ads-twitter.com https://static.hotjar.com
            https://us-assets.i.posthog.com https://www.clarity.ms
            https://www.googletagmanager.com https://www.redditstatic.com
connect-src 'self' https://your-buildbase-api-host
            https://ad.doubleclick.net https://www.google-analytics.com
            https://www.google.com
img-src     'self' https://ad.doubleclick.net
            https://googleads.g.doubleclick.net https://www.facebook.com
            https://www.google.com

The console shows the script-src line of this list under Settings › Tracking & Tags. It is the full list for every provider, not only the ones you use, so trim it to the providers you have enabled. The connect-src and img-src lines are only here.

script-src alone is not enough. It loads the tags, and then connect-src and img-src block every hit they send - GA4 records nothing, and no conversion reaches Google Ads or Meta, while the page looks fine. The connect-src and img-src origins above are the ones measured for GA4, Google Tag Manager, Google Ads and Meta under an enforcing policy. For the other providers, load the page with the policy on and add what the browser console reports as refused.

Three reports are expected and need no change:

• Google Ads also pings the visitor's own country domain - www.google.co.in, www.google.de and so on. No policy can wildcard a top-level domain, so this audience ping is blocked. The conversion still goes through www.google.com.
• One script-src 'eval' report on page load. It comes from a feature check in a validation library bundled with the SDK. The library tries Function("") once and falls back when the policy refuses it. Do not add 'unsafe-eval' for it.
• GA4 can use other collection hosts for some properties, such as analytics.google.com or a regional one. If one is reported refused, add it.

Hosted auth pages load your tags

The hosted login, registration and verification screens load the scripts you attached to that app's auth client, resolved from the sign-in request rather than from anything configured per deployment. They fire sign_up and login there too, at the moment the account exists and the moment the session does.

This is worth having because the page where somebody actually signs up is the highest-intent page in your funnel, and it is the one page your own pixel cannot reach - it is not on your domain. Measuring only the click in and the return out loses everyone who abandons in between, which is most of the people you are paying to find.

Nothing loads until the visitor's consent answer arrives with them. See Consent.

One tag, one place

If a tag is already on the page - your own leftover snippet, or a GTM container that also fires GA4 - the SDK detects it and skips its own install rather than loading it twice. Double-installing doubles every conversion, and there is no way to tell which of the two you meant to keep.

Check useTracking().installed to see what the SDK actually put on the page.

Next

• Overview - attaching a tag to an app.
• Events - conversion labels in practice.