A reader who lands on an article from a registered investment adviser (RIA) and later books a call leaves a trail. That trail exists only if the content library and the customer relationship management (CRM) system share one identifier. The fix is small. Give every published page a fixed ID. Pass that ID through the booking form. Store it on the contact record. Once that is in place, the funnel is a set of linked records rather than a guess. Those records also help the firm show what it published and when.
This article explains the data structure, walks through one example, and states what the record can and cannot prove.
Why the Content Library and the CRM Drift Apart
Most RIAs run two systems for two different jobs. The content library holds articles, newsletters, webinar pages, and approved disclosures. The CRM holds households, prospects, notes, and meeting history.
Each system is tidy on its own. The gap sits between them. A prospect reads three articles, then fills out a "schedule a call" form. The CRM records a new lead. It usually records a source such as "website" or "organic." It does not record which article the person read, which version of that article was live, or who approved it.
That missing link is the whole problem. Without it, marketing cannot see which content leads to calls. Compliance cannot easily reconstruct what a prospect saw before reaching the advisor.
The Four Records That Must Share One Key
Think of the structure as four linked records. Each one points back to the content ID.
- Content record
- Content ID (fixed, never reused)
- Version record
- Version number and publish date
- Reviewer and approval date
- Disclosure text attached to that version
- Booking event
- Content ID and version number the visitor last viewed
- Timestamp
- Meeting record
- Booking event it came from
- Outcome status entered by the advisor
The content ID is the key. It never changes, even when the page address does. Page addresses (URLs) get edited, redirected, and retired. IDs do not.
The version record matters as much as the ID. An article updated in March is a different document from the one published in January. If the CRM stores only "article 114," it cannot say which text the prospect read.
A Worked Example: One Article, One Booked Call
Marcus is a composite, an invented advisor, not a client of ours. He runs a small RIA and publishes a guide on how his firm structures its annual review meetings. The guide describes the firm's process. It does not give investment advice.
Here is the path in the system.
- The guide is assigned content ID 114, version 2. The record stores the approval date and the disclosure text that appears at the foot of the page.
- A visitor reads the guide. The page includes a "book a conversation" button.
- The button opens the booking form. The form carries two hidden fields: content ID 114 and version 2.
- The visitor picks a time. The scheduling tool creates a booking event and writes both values to a new CRM contact.
- Marcus meets the prospect. Afterward, he updates the meeting status in the CRM.
Six months later, someone at the firm can open that contact and see the guide, the version, the approval date, and the disclosure text. Nobody has to search email for it.
Carrying the Page ID Through the Booking Form
The handoff has three common mechanisms. Each has a weakness.
Hidden Form Fields
The page writes the content ID into fields the visitor never sees. This works well when the form lives on the same page or the same domain. It breaks when the booking tool sits on a separate domain that does not accept the values.
Link Parameters
The button's link carries the ID in the URL, often as a urchin tracking module (UTM) parameter. The booking tool reads it and stores it. This works across domains. It fails if someone edits the link or if the visitor arrives from a saved bookmark.
First-Party Cookies
The site remembers the last content viewed and attaches it at booking. This captures a path across several pages. It depends on the visitor's browser settings and consent choices, so it will have gaps.
Whichever method the firm uses, one rule helps. Store the raw value exactly as received. Do not turn it into a friendly label at capture time. Labels change. The ID stays the same.
Why This Becomes Evidence
The Securities and Exchange Commission (SEC) adopted a marketing rule for investment advisers. Alongside it, the recordkeeping rules require advisers to keep copies of advertisements they disseminate. Whether a particular page counts as an advertisement is a question for the firm's compliance team. The data structure does not answer it.
What the structure does is make the copy findable. SEC staff and enforcement actions have pointed to advisers that could not produce earlier versions of their webpages, because the pages were revised without a saved copy. A version record tied to a content ID is a direct answer to that kind of gap.
Staff have also observed that some advisers did not keep copies of material posted to social media. The same logic applies to any owned channel. If a post, page, or newsletter sends readers to a booking form, it needs an ID and a stored copy.
The CRM adds a second layer. It shows which published item a prospect actually reached before contacting the firm. That is a record of the firm's own funnel, held in the firm's own system.
What the Record Cannot Show
The record has limits, and they should be stated plainly.
- It cannot prove a prospect read the page. It shows the page was the last one viewed before booking.
- It loses the trail when a reader switches devices, for example reading on a phone and booking from a laptop.
- It does not replace a compliance review. It documents what was published and approved. It does not show the content met any rule.
- It will not capture a referral from a client who read the article and then phoned the office.
An honest source field reflects this. Mark each booking as "tracked path," "partial path," or "unknown." A CRM full of confident labels on uncertain data is harder to defend than one that admits gaps.
A Field Template for the CRM
This is a starting layout. Adjust the names to fit your CRM.
- Content ID: [fixed identifier for the page or asset]
- Version number: [version live when the visitor viewed it]
- Publish date: [date this version went live]
- Approver: [reviewer's name and title]
- Approval date: [date the version was approved]
- Disclosure text version: [identifier for the disclosure shown on the page]
- Capture method: [hidden field, link parameter, or cookie]
- Path confidence: [tracked, partial, or unknown]
- Booking timestamp: [date and time of booking]
- Meeting outcome: [status entered by the advisor after the meeting]
Build the structure once, then keep it consistent. The value comes from every page, form, and booking carrying the same fields in the same order.
