Turn tracking requirements into a reviewed attribution setup
Collect website and lead-tracking requirements through a structured interview. Prepare a configuration and a test plan for the analytics owner to approve.
How this works
An attribution setup depends on decisions that are easy to omit when copying a generic script: what to retain, when collection is allowed, how navigation works and where values should arrive. Use an interview to make those decisions explicit before generating anything for deployment.
The assistant prepares a configuration artifact and validation evidence. It does not decide the organization’s privacy policy or infer consent from browsing behavior. Where deployment access is absent, a local configuration and test checklist are a complete first deliverable.
Before you start
Tracking owner
Identify who maintains the site, forms, CRM and analytics definitions.
Approved policy
Obtain the current consent behavior and permitted field list from the responsible owner.
Staging route
Use a test page or staging environment and synthetic lead records for validation.
Prepare the inputs
- site_map
- Required
domains, forms and navigation inventory
Include redirect domains, single-page routes and embedded forms.
- field_policy
- Required
approved fields, purposes and retention
Mark prohibited fields and conditions; missing approval remains unresolved.
- destination_map
- Required
CRM or analytics field identifiers
Check field type, length, expected casing and update semantics.
- deployment_mode
- Required
tag manager or standalone
Confirm the actual platform and avoid creating a second tracker.
Implementation, step by step
Inventory the current path
- Follow a representative acquisition link through landing page, navigation and form submission in the permitted test environment.
- Record existing tags and destination mappings before proposing additions, including which team owns each handoff.
Checkpoint: The complete lead path and current collection points are documented.
Interview the requirements owner
- Ask which first-touch or later-touch values matter, which campaign identifiers are permitted and when values should reset.
- Resolve consent defaults, withdrawal behavior, redirects and single-page transitions. Leave unresolved answers visible instead of supplying convenient defaults.
Checkpoint: Every configuration decision has an approved value or an open question.
Build the mapping
- Map each permitted source parameter to storage and destination fields; define empty, repeated and overlong values.
- Specify deterministic precedence for competing values and clarify whether an existing lead record may be updated.
Checkpoint: A field map covers source, transformation, destination and collection condition.
Generate the staged artifact
- Create the smallest configuration supported by the selected deployment mode. Keep environment identifiers configurable.
- Add a change note explaining each option and a removal plan; preserve the previous setup for comparison.
Checkpoint: The artifact is reviewable without deploying it.
Exercise representative journeys
- Test allowed and denied consent, direct visits, campaign visits, redirects and repeat submissions with synthetic identifiers.
- Compare observed destination values with the field map and check that no duplicate tracking event was introduced.
Checkpoint: The test report records expected and actual values for each journey.
Hand off for controlled release
- Resolve failures or record explicit holds. Give the owner the artifact, mapping, test evidence and rollback instructions.
- If deployment is authorized, verify the live destination using synthetic data after release; otherwise label the setup as a draft.
Checkpoint: The status distinguishes prepared, tested and deployed.
Decisions along the way
Consent behavior is undefined
Stop collection-related configuration and ask the policy owner to supply the rule.
A domain transition loses values
Document the exact transition and use only an approved transfer method; do not append sensitive fields to URLs.
What you will produce
tracking-config.json
JSONA configuration specification or platform-specific import draft.
Include: deployment_mode · environment · fields · precedence · consent_conditions · open_questions
tracking-tests.csv
CSVSynthetic checks against the agreed tracking behavior.
Include: journey · consent_state · expected · observed · result · evidence
Check the result
- Verify that prohibited fields never appear in logs or destination records.
- Check direct visits do not inherit unrelated campaign values.
- Confirm a denied-consent journey follows the approved policy.
When something goes wrong
Existing tag conflicts
Disable the draft change and reconcile ownership before retesting.
CRM write cannot be verified
Keep deployment unverified; inspect an authorized export rather than assuming receipt.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: retain campaign source for a lead form.
Inputs
Campaign value source=partner is permitted after consent. A form on a second subdomain maps to acquisition_source; test users include one consenting and one declining visitor.
Expected result
The consenting journey produces partner in the mapped field. The declining journey follows the supplied no-storage rule. A cross-domain failure stays open and blocks a successful test status.
Run a small pilot
Start small
One form and one campaign path in staging.
Record the baseline
Measure field completeness and duplicate events in the existing setup using synthetic submissions.
Agree success criteria
All required journey checks pass with no prohibited-field collection.
Stop or revise
Stop if consent rules are unclear or tracking writes data outside the approved destination.
Keep the scope clear
- Configuration does not establish legal compliance.
- External deployment requires authorization for the target site and environment.
Check before using
The analytics and privacy owners approve collection behavior and deployment.
Business activities
- Handle inbound enquiries
- Run advertising and acquisition tests
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Website architecture · Approved consent requirements · CRM destination fields
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow