That’s a very common headache with third-party tools like Wistia Live when trying to nail down Contact Create attribution in HubSpot.
You’ve done all the right things by setting up the Campaign, Marketing Event, and Workflow, and testing the net-new contact scenario.
The key issue is often in how the Original Source property gets stamped when the contact is created via a third-party integration, especially if it’s a list sync or a server-side action that doesn’t capture the full web session context.
When a form submission happens on an embedded Wistia form or even a HubSpot form used on Wistia’s live events platform, the contact is often created or updated in HubSpot via an API call, not directly through a standard page view followed by a submission that HubSpot’s tracking code recognizes as a `Form Submission` or `Page View`.
If the contact is created via the API without the necessary context, the Original Source properties (which are what drives the Campaign Attribution report for Contact Create) might be set to Offline Sources or Other Campaigns or simply not captured correctly as an interaction event linked to the initial page where the user saw the webinar registration.
The Campaign Attribution report relies on key events like `Page View` (or the initial visit) and `Form Submission` leading to the creation of the contact to assign credit, and that linkage is what often breaks with server-side integrations.
HubSpot even explicitly notes that data from static lists or workflows isn’t used in attribution reports, which you found out with your static list test.
The Marketing Event association is great for reporting on engagement after the contact is created or registered, but it doesn’t always retroactively fix the Original Source for the contact create moment.
A more robust, although more complex, solution for complete, multi-touch attribution that won’t break with third-party forms involves stitching the user journey together using server-side tracking, which combines data from multiple platforms.
This involves using the HubSpot API to feed granular Standard Events back into HubSpot, alongside data from other sources.
Here is the better solution: use the HubSpot API along with the Wistia Data API, the Google Analytics Data API, Google Tag Manager, and a server-side tagging service like Stape or your own Google Cloud Platform environment.
The process works by capturing the user’s unique client ID from HubSpot and/or Google Analytics client ID via Google Tag Manager (GTM) when they land on the page.
When the user registers on Wistia, you use GTM to send the HubSpot and Google Analytics IDs to the server-side tagging environment (like Stape).
The server then uses the Wistia Data API to receive the registration data.
With the contact’s email from Wistia and the stored IDs, you then call the HubSpot API to manually send a Standard Event like `Form Submission` or a custom event to the contact’s timeline, ensuring you include the necessary context, like the original URL and the captured HubSpot/Google Analytics IDs.
This approach guarantees a consistent data flow, allows you to clean and normalize the data before it hits HubSpot or Google Analytics, and explicitly ties the conversion back to the user’s initial tracking IDs, thus giving credit where credit is due in the Contact Create attribution reports, even for third-party platforms.