SourceTag

Troubleshooting

Troubleshooting

This page covers the most common issues people run into with SourceTag and how to fix them.

Script not loading

Symptoms: No _sourcetag cookie is created. No hidden fields appear in forms. window.__sourcetag is undefined in the console.

Check the page source. Open developer tools, go to Elements, and search for SourceTag. If the script tag isn’t in the HTML:

  • Confirm you’ve added the script tag to your site (see the installation guide for your platform)
  • If using WordPress, check that the SourceTag plugin is activated and your Site ID is entered in Settings > SourceTag
  • If using GTM, check that the tag is published and firing

Check the Network panel. If the script tag is present but the file returns a 404:

  • You may not have clicked Generate Script in the SourceTag dashboard. The script file only exists after you generate it.
  • Double-check the Site ID in the script URL matches your site in the dashboard

Check for JavaScript errors. Look at the Console panel for any errors. A syntax error in another script on the page could prevent SourceTag from running, though this is uncommon since the script runs in an IIFE.

[IMAGE: Screenshot of browser Network panel showing a 404 error for st.js]

Hidden fields not populated

Symptoms: The script loads and the cookie is set, but form submissions don’t contain any SourceTag data.

Check that field names match. The hidden fields in your form need name attributes that match the field names configured in your SourceTag dashboard. Open the form in developer tools and check the hidden inputs.

Common mismatches:

  • Extra spaces in the field name
  • Wrong prefix (ft_ instead of st_fc_, or lt_ instead of st_lc_)
  • Case differences (ST_FC_Channel vs st_fc_channel)

Check that the form is detected. SourceTag looks for <form> elements on the page. If your form doesn’t use a standard <form> tag (some JavaScript frameworks render forms as <div> elements), SourceTag won’t find it. Check the Elements panel to see what HTML element your form uses.

If you need to target a non-standard element, you can set a custom form selector in Advanced Mode on the Fields page.

Check the timing. Open a page with a form, then run in the console:

document.querySelectorAll('form').forEach(function(f) {
  console.log('Form found:', f, 'Processed:', !!f._stProcessed);
});

If _stProcessed is true, SourceTag has found and processed the form. Inspect the hidden fields inside it.

Caching plugins interfering

Symptoms: The script works on some pages but not others. Or it works after you clear the cache but breaks again later.

WordPress caching and optimisation plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache, Autoptimize, SG Optimizer) can interfere in two ways:

JavaScript minification/combination

Some caching plugins try to combine or minify all JavaScript files on the page. This can break the SourceTag script if the minifier doesn’t handle the IIFE correctly.

Fix: Exclude the SourceTag script from minification and combination. In most caching plugins, you can add the script URL to an exclusion list:

cdn.sourcetag.io/scripts/

or:

st.js

The exact setting location varies by plugin:

  • WP Rocket: Settings > File Optimization > Excluded JavaScript Files
  • Autoptimize: Settings > Autoptimize > JS, CSS & HTML > Exclude scripts from Autoptimize
  • LiteSpeed Cache: Settings > LiteSpeed Cache > Page Optimization > Tuning > JS Excludes
  • W3 Total Cache: Performance > Minify > JS > Never minify

[IMAGE: Screenshot of WP Rocket exclusion settings with the SourceTag script URL added]

Full-page caching and server-side cookies

If you’re using the WordPress plugin’s server-side cookie feature, full-page caching can prevent the PHP setcookie() call from running. See Safari Cookies for details on how to handle this.

Ad blockers

Symptoms: SourceTag works for you but not for some visitors. Cookie and hidden fields are intermittently missing.

Some ad blockers and privacy extensions block third-party tracking scripts. Since SourceTag loads from cdn.sourcetag.io, certain blockers may flag it.

How common is this? Ad blocker usage varies. Roughly 25-30% of desktop users globally have an ad blocker installed, but most blockers focus on known advertising and analytics domains. SourceTag isn’t on the major filter lists, so the impact is typically small.

CNAME workaround: If ad blockers are a concern, you can set up a CNAME record on your domain that proxies to the SourceTag CDN. For example:

scripts.yoursite.com pointing to cdn.sourcetag.io

Then update the script tag URL to use your subdomain:

<script src="https://scripts.yoursite.com/scripts/YOUR_SITE_ID/st.js" async></script>

This makes the script appear as a first-party resource, which most ad blockers won’t touch.

Note: CNAME setup requires access to your domain’s DNS settings. The specifics depend on your DNS provider.

Forms in popups and modals

Symptoms: Forms on the main page work fine, but forms inside popups or modals don’t have hidden fields.

SourceTag uses a MutationObserver to watch for new forms added to the page after initial load. This should catch forms that appear in popups, modals, slide-ins, and other dynamically loaded containers.

If it’s not working:

Check the form element. Make sure the popup form uses a standard <form> HTML element. Some popup builders render forms as styled <div> elements without a real <form> tag.

Check the timing. The MutationObserver triggers when new DOM nodes are added. If the form HTML is already in the page (just hidden with CSS), the observer won’t fire because nothing was added. In that case, SourceTag would have already processed the form on initial page load. Inspect the hidden fields to check.

Check for iframes. If the popup loads the form in an iframe from a different domain, SourceTag can’t access it due to browser security restrictions. Use data-st-iframe on the iframe element to pass attribution data as URL parameters instead. See Forms in Popups and Modals for details.

Salesforce Web-to-Lead forms

Salesforce Web-to-Lead forms use their own field naming convention. To map SourceTag fields to Salesforce fields, add the data-st-field attribute to each hidden input:

<input type="hidden" name="00N..." data-st-field="st_fc_channel">

The data-st-field attribute tells SourceTag which value to populate into that field, even when the field’s name attribute doesn’t match the SourceTag field name.

Iframe forms (Zoho, embedded tools)

If your form is embedded in a cross-domain iframe (common with Zoho, Typeform, and other hosted form tools), add data-st-iframe to the iframe element:

<iframe data-st-iframe src="https://forms.example.com/your-form"></iframe>

SourceTag will append attribution data as URL parameters to the iframe’s src attribute. The form tool can then read these values.

Cookie not working across subdomains

Symptoms: The cookie is set on www.example.com but not available on blog.example.com, or vice versa.

SourceTag auto-detects the cookie domain from the current hostname, setting it to the root domain (e.g. .example.com). This should work across subdomains automatically.

If it’s not working:

  • Check that both subdomains have the SourceTag script installed
  • Verify the cookie domain in the browser dev tools (Application > Cookies). The domain should show .example.com, not www.example.com
  • If you’re using a cookie consent tool, make sure it’s not restricting the cookie to a specific subdomain

Device detection

SourceTag detects device type (Mobile, Tablet, Desktop) using screen.width, not window.innerWidth. This means the device type reflects the physical screen size rather than the current browser window size. Resizing a browser window on a desktop won’t change the device type to Mobile.

Form data not reaching CRM

Symptoms: Hidden fields are populated in the form, but the data doesn’t appear in your CRM.

This usually means the form-to-CRM mapping is incomplete:

  1. Check that CRM custom fields exist. Go to your CRM and verify you’ve created custom contact/lead fields for each SourceTag field name. See the setup guide for your CRM.
  2. Check the field mapping. In your form builder or CRM integration, make sure each hidden field is mapped to the corresponding CRM field.
  3. Check the internal field names. Some CRMs modify field names (e.g. HubSpot lowercases everything, Salesforce appends __c). Make sure the form field names match the CRM’s internal field names, not the display labels.

Cookie not persisting

Symptoms: The cookie is set on first visit but disappears on subsequent visits.

  • Safari/iOS browsers: This is likely ITP. See Safari Cookies.
  • Cookie consent tool blocking it: If you’re using a cookie consent banner and the visitor hasn’t consented, your consent tool may be stripping the cookie. Check your consent tool’s configuration.
  • Incognito/private browsing: Cookies are cleared when the incognito window is closed. This is expected behaviour.

Something else?

If you’re stuck on an issue not listed here, check:

  • Testing for step-by-step verification
  • FAQ for common questions
  • Contact support through the SourceTag dashboard