A visitor can open campaign A, duplicate the tab, click campaign B in another tab, and submit a multistep WPForms flow later. Shared localStorage or broad cookies can let the newest tab overwrite attribution for every journey, while sessionStorage alone can behave unexpectedly when a tab is duplicated.
Use this for paid search, paid social, email, affiliate, and partner campaigns that send visitors into multistep WPForms flows or long consideration journeys.
Quick answer
Create a unique journey ID when the landing session starts, bind first-touch and latest-touch values to that ID, carry it through every WPForms step and hidden field, and define how a duplicated tab inherits or forks the journey. Test two campaigns in parallel before trusting CRM attribution.
What to check first
- Document where first touch, latest touch, click IDs, referrer, landing page, and journey ID are stored.
- Define whether a duplicated tab should continue the same journey or fork on the first new campaign landing.
- Bind hidden field values to one journey record instead of global latest values.
- Persist the journey ID through multistep navigation, validation errors, back buttons, and delayed submission.
- Compare browser state, WPForms entry, webhook, CRM record, and ad-platform upload.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define journey, tab, and form instance identifiers and their lifetimes. | Document where first touch, latest touch, click IDs, referrer, landing page, and journey ID are stored. | Parallel campaign tabs submit the intended first and latest touch values. |
| Store attribution as a versioned journey record rather than loose global keys. | Define whether a duplicated tab should continue the same journey or fork on the first new campaign landing. | Journey ID remains stable through validation, back navigation, and multistep transitions. |
| Populate WPForms hidden fields from the bound journey at each critical step. | Bind hidden field values to one journey record instead of global latest values. | Duplicate behavior matches the documented inherit or fork rule. |
| Make duplicate-tab inheritance or forking explicit and testable. | Persist the journey ID through multistep navigation, validation errors, back buttons, and delayed submission. | WPForms, webhook, CRM, and downstream conversion payload agree on the journey. |
Why this usually happens
- A single localStorage key is shared across every tab for the same origin.
- A duplicated tab can copy sessionStorage state, creating two tabs with the same identifier.
- Hidden fields are populated once but later steps read a newer global attribution record.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
journey_id: jrn_8f2c1a7d
first_touch: { source: google, medium: cpc, campaign: spring, captured_at: 2026-08-08T13:00:00Z }
latest_touch: { source: partner, medium: referral, campaign: demo, captured_at: 2026-08-08T13:18:00Z }
tab_instance_id: tab_31ab
form_instance_id: form_5520
duplicate_policy: fork_on_new_campaign
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Campaign A only | Open A and finish all steps | A first touch, A latest touch, stable journey ID |
| Duplicate same journey | Duplicate A tab before step two | Defined shared or forked behavior with no missing fields |
| Parallel campaigns | Open A, then B in a second tab | Each submission keeps the intended campaign journey |
| Validation and return | Fail validation, navigate back, then submit | Journey ID and touch fields remain unchanged by the error |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Define journey, tab, and form instance identifiers and their lifetimes.
- Store attribution as a versioned journey record rather than loose global keys.
- Populate WPForms hidden fields from the bound journey at each critical step.
- Make duplicate-tab inheritance or forking explicit and testable.
- Reconcile the submitted entry through webhook, CRM, and advertising upload.
Decision rule
Keep the same journey when a duplicate tab continues the same landing context. Fork a new journey when the tab receives a new attributable campaign according to the written attribution policy. Never allow one tab's latest touch to silently rewrite another submitted journey.
Production verification checklist
- Parallel campaign tabs submit the intended first and latest touch values.
- Journey ID remains stable through validation, back navigation, and multistep transitions.
- Duplicate behavior matches the documented inherit or fork rule.
- WPForms, webhook, CRM, and downstream conversion payload agree on the journey.
Field notes
- Write the duplicate-tab policy before implementation because both inherit and fork can be valid business choices.
- Use an opaque random journey ID with no personal data.
- Retain field-level source timestamps so first touch and latest touch can be explained.
Questions teams ask during testing
Should duplicate tabs share a journey ID?
They can until one tab receives a new attributable campaign, but the policy must be explicit and the implementation must prevent cross-tab overwrites.
Why add a tab instance ID?
It helps detect copied session state and trace which browser path produced the submitted record.
Where should UTM values be sent?
Send the normalized journey fields with the form entry, webhook, CRM record, and any consented advertising conversion payload.
Mistakes to avoid
- Do not keep every active journey in one shared latest-value key.
- Do not assume sessionStorage always creates a unique tab identity after duplication.
- Do not regenerate the journey ID on every form step.
- Do not overwrite first touch when a later campaign updates latest touch.
What to tell the client or owner
Provide the storage schema, duplicate policy, fixture URLs, tab order, WPForms entry fields, webhook payload, CRM record, and the exact point where values diverge.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WPForms campaign attribution.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references