How this guide was built
This documentation-led data contract combines a dated audit of HubSpot property architecture, Google Analytics event guidance, and current involve.me CRM and integration documentation with a normalized 30-field starter dictionary, one hypothetical qualification-to-booking record, and ten fixed tests. Sources were rechecked on October 9, 2026. It is not an authenticated account audit, privacy assessment, database schema, or claim that one field set fits every funnel.
What is an AI funnel data dictionary?
An AI funnel data dictionary is a controlled specification for the fields and events shared across the visitor experience, decision logic, contact record, integrations, automation, and reporting. It distinguishes declared inputs from derived values, current contact state from immutable event evidence, and human-approved facts from AI-generated text.
The dictionary is the translation layer between visible questions, qualification rules, stable result IDs, CRM properties, workflow conditions, integration payloads, and analytics events. Without it, different systems can use the same label for different meanings or silently convert missing, corrected, or withdrawn values.
Give every field nine attributes
Do not reuse one name for different meanings. Score might mean raw points, normalized percentage, fit tier, or predicted likelihood. Give each meaning a separate definition and machine key.
| Attribute | Purpose |
|---|---|
| Business name | Human-readable meaning |
| Machine name | Stable integration and analytics key |
| Definition | Exact inclusion, exclusion, and unit |
| Source | Visitor, rule, system, integration, or human |
| Type | Text, number, boolean, date, datetime, enum, or ID |
| Allowed values | Controlled set, range, or format |
| Update rule | Immutable, replace, append, recalculate, or clear |
| Owner | Team accountable for meaning and quality |
| Sensitivity and retention | Handling, access, and deletion rule |
Use this 30-field starter dictionary
The following starter set covers acquisition, interaction, decision, contact continuity, action, delivery, and governance. Remove fields with no declared purpose. Add domain-specific fields only when they have an owner, consumer, and retention rule.
Do not place sensitive or free-form contact data into analytics simply because the CRM stores it. The destination is part of the definition.
| # | Machine name | Type | Source | Meaning |
|---|---|---|---|---|
| 1 | session_id | ID | System | One anonymous visit or interaction session |
| 2 | source | Text | Acquisition | First captured traffic source |
| 3 | medium | Text | Acquisition | Acquisition medium |
| 4 | campaign | Text | Acquisition | Campaign identifier |
| 5 | landing_variant | ID | Experiment | Experience or variant shown |
| 6 | funnel_version | ID | Release | Published rules and content version |
| 7 | started_at | Datetime | System | Meaningful funnel start |
| 8 | current_step | ID | System | Last confirmed step |
| 9 | completed_at | Datetime | System | Valid completed submission time |
| 10 | answer_set_version | ID | Release | Question and answer schema version |
| 11 | declared_need | Enum | Visitor | Primary job or problem selected |
| 12 | declared_timeline | Enum | Visitor | Self-reported decision timeframe |
| 13 | declared_budget_band | Enum | Visitor | Approved budget band, not an inferred value |
| 14 | constraint_flags | Set | Visitor or rule | Declared exclusions or delivery constraints |
| 15 | consent_state | Enum | Visitor or system | Purpose-specific permission state |
| 16 | consent_recorded_at | Datetime | System | When the current permission was recorded |
| 17 | raw_score | Number | Rule | Sum before overrides or normalization |
| 18 | score_version | ID | Release | Version of weights, bands, and overrides |
| 19 | qualification_tier | Enum | Rule | Approved fit tier |
| 20 | override_reason | Enum | Rule or human | Why numerical score did not control the result |
| 21 | result_id | ID | Rule | Stable outcome identifier |
| 22 | result_explanation | Text | Rule or AI | Grounded explanation shown to the visitor |
| 23 | contact_id | ID | CRM | Stable contact identifier |
| 24 | contact_match_method | Enum | CRM | How the submission matched or created a record |
| 25 | segment_id | ID | CRM | Current operational segment |
| 26 | owner_id | ID | Routing | Accountable assignee, team, or queue |
| 27 | next_action | Enum | Rule or workflow | Approved immediate action |
| 28 | workflow_state | Enum | Automation | Active, waiting, stopped, failed, or complete |
| 29 | last_delivery_status | Enum | Delivery | Latest relevant email, webhook, or action state |
| 30 | correction_status | Enum | Governance | None, requested, applied, rejected, or deleted |
Separate state from evidence
Contact state answers what is true now. Event evidence answers what happened at that time. A contact may currently belong to a high-fit segment, but the original submission should still preserve the score version, result ID, assignment, and timestamp that produced the historical action. Overwriting history makes attribution and remediation unreliable.
Use immutable events for start, answer correction, completion, result view, contact creation, segment transition, assignment, message send, click, booking, payment, consent withdrawal, and deletion. Use current properties for active assignee, active segment, latest qualification tier, lifecycle state, and next action.
Use explicit types and controlled values
Avoid storing every value as text. Numbers need units and valid ranges. Dates and datetimes need timezone rules. Booleans need a defined unknown state when absence is not equivalent to false. Enumerations need stable internal values even if visible labels change.
HubSpot's current documentation separates the type and fieldType decisions: storage type controls whether a value is boolean, enumeration, date, datetime, string, or number, while fieldType controls how the value is presented. It documents UTC date and datetime handling, system and custom unique identifiers, and owner assignment by ID. The general lesson is that storage, presentation, identity, and ownership are separate decisions.
Sources: HubSpot Properties API
Worked example: qualification-to-booking record
A hypothetical B2B readiness assessment records campaign ops_q4, funnel version 2026-10-09.1, declared timeline 0_90_days, budget band 25k_50k, raw score 17, score version score_v3, qualification tier high, result ID ready_now, and next action book_strategy_call. A hard exclusion is false, so no override applies.
The CRM matches the email to contact c_1042, records the match method, updates segment high_fit_ready_now, assigns enterprise_east, and starts booking_sequence_v2. The immutable completion event retains the original values even if the contact later corrects budget or is reassigned. A booking event stops the sequence and updates current workflow state to complete.
This is a reproducible schema fixture, not a real person, authenticated product record, or benchmark.
Validate the dictionary with ten fixed tests
Run these checks before launch and whenever a question, rule, property, integration, workflow, or retention policy changes.
| # | Test | Expected evidence |
|---|---|---|
| 1 | Definition ownership | Every rule-driving field has one definition and owner |
| 2 | Enum control | Unknown labels are rejected rather than silently mapped |
| 3 | Numeric boundary | Units and inclusive or exclusive rules are preserved |
| 4 | Time round-trip | Dates and datetimes survive without timezone drift |
| 5 | Repeated submission | The declared match and merge policy is applied |
| 6 | Correction | Current state changes while historical event evidence remains |
| 7 | Consent withdrawal | Incompatible actions stop |
| 8 | Cross-system mapping | Names and types survive without truncation or loss |
| 9 | Missing optional value | Null remains null; no default fact is invented |
| 10 | Deletion and retention | Downstream copies follow the declared policy |
What do current product sources establish?
The current involve.me CRM page says every submission creates a contact with its answers, score, and outcome attached. It documents typed custom properties, dynamic segments, timeline activity, integration syncs, workflow updates, and the ability to assign each lead to a team member. Those documented behaviors support contact context and operational ownership in the same platform.
The current integrations directory documents native CRM, marketing, analytics, payment, and collaboration destinations plus custom webhooks and Zapier. It specifically describes sending funnel responses, scores, segments, and contact data to systems such as HubSpot and Attio. This supports a mapping layer, but it does not prove that every destination accepts the same types, identifiers, limits, or merge rules.
Google Analytics documents recommended events and their parameters as optional events that require configuration. Use them where the meaning fits; otherwise define a controlled custom event. Analytics events should describe behavior, not become a shadow store for sensitive contact records.
Sources: involve.me built-in CRM, involve.me integrations, Google Analytics recommended events
What are the limitations?
This is a documentation-led data contract, not an authenticated account audit, privacy assessment, database schema, or claim that 30 fields fit every funnel. Data architecture depends on purpose, jurisdiction, product configuration, integration limits, identity rules, retention, and sensitivity.
CRM properties are not a substitute for an event ledger, and analytics events are not a suitable store for contact-level sensitive data. A platform can document mapping and still require plan, account, field, destination, and authentication checks before launch.
Revalidate APIs, naming limits, data types, available mappings, merge behavior, assignment permissions, and retention in the intended account. Send corrections through the site contact page.
The decision in one paragraph
A reliable AI funnel data dictionary gives every decision-driving field one meaning, machine key, type, owner, update rule, destination, and retention policy. It preserves immutable evidence while current contact state changes, so the visible result, CRM record, assignment, workflow, integration, and report can be reconciled.