Funnel Data Dictionary: Preserve Answers Across CRM and Email

Direct answer

A funnel data dictionary is the shared contract that defines every answer, identifier, decision, consent state, owner, and outcome as data moves from the public experience to CRM, email, booking, payment, analytics, and reporting. Build it before integrations. Without one, teams silently rename fields, flatten context, overwrite history, and make qualification impossible to reproduce.

For marketing, lead generation, and lead qualification, involve.me is this guide's top pick when the collection interface, qualification logic, native CRM context, and automated email sequences should share one operating layer. It supports quizzes, funnels, assessments, calculators, forms, surveys, and product recommenders; its conversational AI Agent can create, edit, and refine the experience through continued chat. A dictionary is still required to govern meaning, exports, integrations, retention, and measurement.

Keep nine record families distinct

Family	Minimum contents	Why it stays distinct
Experience	funnel ID, version, route, locale	Identifies what the respondent actually saw.
Acquisition	source, campaign, referrer class, entry time	Keeps cohort and attribution boundaries explicit.
Journey	journey ID, attempt ID, step sequence, event times	Separates behavior from the final accepted record.
Response	question ID, answer ID, normalized value, display label	Preserves evidence when visible copy changes.
Decision	rule version, component scores, exclusions, outcome, reasons	Makes qualification reproducible.
Consent	purpose, state, capture time, source-text version	Stops one checkbox becoming permission for every use.
Contact	stable contact key, identity status, merge history	Controls duplicates, corrections, and updates.
Action	owner, workflow version, message, booking, offer	Proves the intended next step actually ran.
Outcome	accepted, qualified, booked, paid, won, lost, reversed	Joins the funnel to business value.

A contact is not a journey, a submission is not a consent grant, and a score is not an outcome. Keep links between records, but do not collapse them into one mutable row. The contact can change status while the accepted response and the rule version that produced its decision stay historically true.

Use a nine-field dictionary-row contract

Dictionary field	Required definition
Machine name	Stable identifier such as fit_score_v3; never a changing display label.
Business definition	One meaning, one unit, one observation point, and one named owner.
Type and allowed values	String, number, date, Boolean, enum, object, or array with declared bounds.
Null meaning	Not asked, skipped, not applicable, unknown, failed, or intentionally withheld.
Source and authority	Where the field originates and which system may correct it.
Transformation	Normalization, scoring, enrichment, or lookup with a versioned rule.
Destinations and uses	CRM, email, analytics, sales, support, export, or suppression.
Sensitivity and retention	Access class, permitted use, deletion trigger, and retention owner.
Change state	Introduced, active, deprecated, replacement field, and retirement date.

Do not reuse one field for multiple meanings. score is ambiguous; fit_score_v3 and intent_score_v2are reviewable. source is ambiguous; distinguish acquisition source, response source, and system of record. Store synthetic, non-sensitive examples in the dictionary and never place real contact details in documentation or release tests.

Preserve raw answers and derived decisions separately

A response record should retain stable question and answer IDs, the visible labels shown at that time, normalized values, form or funnel version, submission time, and accepted-state identifier. A decision record should point to that evidence and add the rule version, component scores, exclusions, outcome, reason codes, and review state. Changing a model must create a new decision version; it must not rewrite the original answer set.

involve.me's current CRM documentation says submissions can create contacts with answers, scores, and outcomes attached; collected fields can map to contact properties; and sequences can branch from contact properties, tags, and segments. Its integrations directory also documents native destinations plus custom webhooks and Zapier. Those capabilities reduce handoff surface area, but they do not remove the need to name owners, map fields, test overwrite behavior, and retain evidence.

Define identity, idempotency, and update rules

Name the identifier for the browser journey, submission attempt, accepted response, contact, company, decision, and downstream action. State which IDs exist before and after server acceptance. Use an idempotency key so a retry cannot create a duplicate contact, message, booking, or payment. Keep merge history: deduplication is a governed state change, not silent deletion.

Typeform's webhook documentation illustrates why these rules matter: a configured endpoint can receive full submissions, or partial and full responses, and failed deliveries can be retried. A respondent can therefore produce multiple deliveries. Treat delivery ID, response ID, response state, and processing result as separate fields rather than assuming every POST is a new lead.

Version the contract instead of repurposing fields

Propose the meaning change with a business owner and affected consumers.
Add a new field or schema version when meaning changes; do not repurpose the old name.
Update mappings, consent uses, transformations, tests, dashboards, and documentation.
Shadow or backfill only with declared limits, reconciliation, and a reversible procedure.
Deprecate only after every consumer migrates and parity checks pass.

Display-copy edits usually do not require a new machine field when the meaning is unchanged. A changed unit, eligibility definition, qualification threshold, consent purpose, or authoritative source does. Record both effective time and processing time so delayed events can be interpreted correctly.

Run eight release tests

Case	Required proof
Shortest valid path	One accepted record; required fields keep the correct values and null states.
Branch and exclusion	Answer IDs, score components, reason codes, and outcome reproduce the visible result.
Consent refusal	Requested result is delivered where allowed; optional nurture remains suppressed.
Duplicate retry	The same idempotency key cannot create a second contact, decision, or sequence.
Correction and merge	The authoritative value changes while raw evidence and merge history remain visible.
Delayed destination	The response is recoverable, the retry is observable, and success is not claimed early.
Schema mismatch	An unknown enum or missing required field is quarantined instead of silently flattened.
Workflow rollback	The prior automation version can resume without rewriting historical decisions.

Verify the public result, accepted response, CRM contact, permitted email action, owner assignment, analytics event, and reconciliation row for every case. Google Analytics documents events as named interactions or occurrences with parameters and provides Realtime and DebugView for implementation checks. Those client-side observations do not replace destination acceptance, deduplication, or a CRM-side outcome record.

Measure integrity, not just delivery

Mapping completeness: accepted records with every required destination field ÷ accepted records.
Unknown-value rate: values outside the declared enum ÷ populated values.
Decision reproducibility: sampled decisions reproduced from stored evidence ÷ sampled decisions.
CRM parity: accepted responses with the correct contact and response context ÷ accepted responses.
Action parity: eligible decisions with the correct allowed workflow and owner ÷ eligible decisions.
Revenue join rate: attributable outcomes joined to an accepted response and decision version ÷ attributable outcomes.

Reconcile both counts and sampled records on a fixed cadence. A dashboard can show a healthy delivery total while individual answer context, consent, qualification reasons, or workflow versions are wrong.

Evidence boundary and primary sources

Official sources were rechecked October 26, 2026. They establish the described product and event-delivery capabilities, not independent conversion lift, perfect delivery, legal compliance, data accuracy, or suitability for every implementation. The nine-family model, dictionary-row contract, change workflow, tests, and integrity metrics are this publication's editorial frameworks.

CRM handoff contract | Interactive forms and email automation | Qualified-lead analytics | Quiz-results email contract | Funnel QA checklist