How to Combine Self-Reported Discovery With Analytics Without Double Counting

When a business asks, “How did you hear about us?” the answer describes what a person remembers or considers influential. Website analytics records digital interactions that its tracking setup can detect, such as a visit from a tagged campaign or a link from another site. Both answers and analytics records can help explain a conversion, such as a completed purchase or signup, but they describe different evidence.

Count each conversion outcome once. Use survey answers and analytics to describe the same purchases or signups from different perspectives; do not add their counts together. This preserves useful clues, such as word of mouth or discovering the business offline, without counting them as extra sales or leads.

What the two measures record

The question determines what a survey answer describes. “What first made you aware of us?” asks about remembered discovery. “What brought you to the site today?” asks about a more immediate visit. A person might answer “a colleague” to the first and arrive through a search engine later. Both answers can be accurate because they describe different moments.

Analytics records activity that its tracking setup can link to a person, a session, or an event. A session is a visit that the analytics platform groups together; an event is a recorded action, such as a form submission. In Google Analytics 4 (GA4), traffic-source dimensions describe activity at different levels: first-user source shows how someone first found the business, session source shows the source for a visit, and event-scoped source can reflect the selected attribution model. Each field answers a different question. Check which field a report uses before comparing it with a survey answer. Google documents these traffic-source scopes.

Attribution is how a platform gives sources credit for a customer’s interactions on the way to a purchase or signup. Some models give all the credit to one source. Others divide it among several interactions. GA4’s data-driven attribution model divides credit among channels based on observed customer paths. Those channel credits show how the model assigns credit; they are not separate counts of unique conversions. Read the GA4 attribution explanation alongside the report’s conversion total.

Keep conversion counts separate from source evidence

Choose one official record for each outcome, such as the CRM record for a submitted lead or the order record for a completed purchase, and count that outcome once. Store the survey answer and analytics details in separate fields or linked records, rather than counting them as additional conversions.

For a matched purchase, for example, analytics might record a search visit before checkout while the buyer says a colleague first mentioned the business. Keep both observations: one describes a tracked visit, the other remembered discovery. Neither one needs to replace the other, and neither creates another purchase.

If your records cannot link survey answers to individual conversions, compare totals and show how many answers or conversions each total includes. Show the total number of conversions, the number of people who answered, and the distribution of answers among respondents. Do not suggest that each answer matches a particular path recorded in analytics.

Label what each total counts. A total of conversions, sessions, people, or attribution credit each measures something different. Some reporting methods give multiple sources full credit for the same conversion. As a result, the source totals can add up to more than the number of conversions. Amplitude documents this behavior for its participation model and distinguishes it from models that allocate a fixed total of credit across sources in its attribution documentation.

Check your own reporting

Define conversions the same way in survey and analytics reports before comparing their data. Then check these points in order:

1. Name the outcome and unit. Decide whether the report counts completed purchases, submitted lead forms, unique people, sessions, or events. Keep different funnel stages out of the same total.
2. Inspect the analytics dimensions and attribution model. In GA4, confirm whether the report uses first-user, session, or event-scoped source. Google warns that its user-acquisition and traffic-acquisition reports use different scopes.
3. Trace a conversion across records. Check whether the same order, form submission, or contact appears in analytics and your business records. Check for events recorded more than once, imported data, or manually added totals that count the same outcome twice.
4. Measure survey coverage. Record how many eligible converters saw the question, how many responded, and how many answers were usable. A result based only on respondents describes those respondents. It does not automatically describe everyone who completed a conversion.
5. Align the question and period. Compare the same conversion group and date range, and distinguish first remembered discovery from the visit or interaction that prompted action.

Keep the original survey wording when you group answers into reporting categories. If a respondent names a creator, event, or community, preserve that answer before mapping it to a broader category. Keeping the original answer lets you review ambiguous mappings and spot sources missing from the choices.

In analytics, check whether campaign parameters remain on the landing page and whether redirects or visits across different domains interrupt tracking. GA4’s documentation describes campaign and traffic-source data and explains that missing source information or stripped campaign parameters can contribute to “direct” or unassigned traffic. A “direct” label does not prove that someone found the business by typing its address or using a bookmark. See Google’s explanation of direct traffic.

Where the signals disagree

When the answers and analytics do not match, investigate the difference instead of forcing them into one answer. A person may remember a colleague, podcast, or event that did not produce a tagged visit. Analytics may record a search visit that happened after the person first heard about the business elsewhere. That difference alone does not show which interaction led to the conversion.

People may remember only part of their journey. They may also understand the question differently or choose the source that seems most relevant to them. Research on news consumption has found differences between recorded pathways and recalled sources in that setting, including cases where people remembered a path more readily than a publisher brand. Those findings support caution about recall, but they provide no correction factor for business “How did you hear about us?” surveys. The Reuters Institute study examined UK desktop news use, not business customer attribution.

Tracking can miss interactions. Source labels depend on the tracking setup. They also depend on how analytics identifies people and which attribution model it uses. Identity features can help link activity, but they cannot confirm that every device or interaction belongs to the same person. Google describes the limits and parts of GA4 reporting identity. Treat analytics as a record of what a defined tracking setup captures, not as a complete account of every influence.

Key Takeaways

• Count each outcome once: Keep one canonical total for purchases, leads, or another defined conversion.
• Preserve separate evidence: Survey answers and analytics data belong side by side, with neither source overwriting the other.
• Label the measure: State whether a report counts people, sessions, events, conversions, or attribution credit.
• Check survey coverage: Show how many converters answered and avoid presenting respondent results as a full-customer census.
• Investigate mismatches: Treat a remembered source and a tracked visit as descriptions of different parts of a journey unless the evidence supports a stronger conclusion.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com