> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dforms/connect/hubspot/attribution.md).
# Landing page & HubSpot attribution
When a form is embedded on your website, dForms tells HubSpot which page the respondent converted on and links the contact to the visits they made before. What HubSpot receives, the three things you n
Most forms live inside your own pages. With the full embed snippet, each submission knows the page it was answered on and, when that page runs your HubSpot tracking code, the visitor's HubSpot cookie. The HubSpot sync uses both to link the new contact to the page views they made before converting.
***
## Where the page comes from
When the form is embedded, the embed script on your page tells the form the page's address and title and, when the page runs HubSpot, the HubSpot visitor cookie (`hubspotutk`). What it sends, the visitor opt-outs and how to turn it off are explained in [Embed on your website](/dforms/share/embed.md#what-your-page-tells-the-form).
When someone opens the form's own link instead, the page is the form itself:
* Its address keeps only the UTM parameters. The other parameters are prefilled answers, so they are left out.
* Its title is the form's public title.
* The HubSpot cookie travels only when the form loads its own HubSpot tracking code, with the **HubSpot tracking ID** under [Tracking & pixels](/dforms/connect/tracking-and-pixels.md). That cookie identifies the visitor on the form's own address, not on your website.
***
## What HubSpot receives
The page reaches HubSpot on completed submissions only, in two places:
| Where | What arrives | The switch it needs |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| The **form submission activity** on the contact | The page's address, its title (the form's public title when the page reported none), the HubSpot page ID on a HubSpot-hosted page, and the visitor's HubSpot cookie. The cookie is what links the contact to their earlier page views. | **Record a form submission in HubSpot** |
| The **note** on the contact | A **Page:** line with the page's address. | **Create a note on completed submissions** |
Both switches are on the HubSpot card. See [Form elements: UTMs, score, outcome, submitted date](/dforms/connect/hubspot/form-elements.md).
If HubSpot refuses the submission because of the page details, for example a cookie it does not recognise, dForms posts it once more without them. The form submission activity still appears on the contact. Only the link to the earlier visits is lost for that submission.
***
## What you need
Three things, all of them:
1. **The right connection and switch.** The private app behind your [HubSpot connection](/dforms/connect/connections.md) has the `forms` and `form-submissions-write` scopes, and **Record a form submission in HubSpot** is on for the form.
2. **One portal.** The connection and the tracking code on your page belong to the same HubSpot portal. A cookie from another portal still arrives, but HubSpot cannot link it to that contact's visits.
3. **The full snippet.** Your page has both the iframe and the embed script, pasted as the editor gives them. A bare iframe passes only your site's address, usually without the path, and never the cookie.
> **💡 Tip:** When the form is embedded on pages that already load your HubSpot tracking code, leave the form's own **HubSpot tracking ID** empty. The embed passes the visit from those pages.
***
## Where you see it
* **In Submissions.** The response panel shows a **Page** row with the page title and its host, and a **HubSpot cookie received** chip when the cookie arrived. The chip means the cookie arrived with the response, not that HubSpot accepted the visit. The cookie itself is never shown. See [Submissions](/dforms/results/submissions.md).
* **In the CSV export.** A **Page URL** column at the end. See [Export to CSV](/dforms/results/export-csv.md).
* **In webhooks.** Each delivery carries a `visit` object. See [Payload & headers reference](/dforms/connect/webhooks/payload-reference.md).
* **In HubSpot.** The form submission activity on the contact's timeline, and the **Page:** line of the note.
Check a response here: the Page row and the HubSpot cookie received chip say what arrived with it.
***
## Good to know
* The cookie is kept only when something on the form can use it: an enabled webhook, or HubSpot with **Record a form submission in HubSpot** on. Otherwise it is dropped before the response is saved.
* With [spam protection](/dforms/connect/spam-protection.md) on, partial submissions are not delivered. The verified complete submission carries the page.
* **HubSpot history** does not show what was sent to HubSpot. Open the response in **Submissions** to check what arrived with it.
## What's next
* [Embed on your website](/dforms/share/embed.md): the snippet and what your page tells the form.
* [Form elements: UTMs, score, outcome, submitted date](/dforms/connect/hubspot/form-elements.md): the switches on the HubSpot card.
* [How the sync works & troubleshooting](/dforms/connect/hubspot/how-sync-works.md): matching contacts by email and reading the history.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.dapta.ai/dforms/connect/hubspot/attribution.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
