Summary
We've changed how Turtl decides which account a reader belongs to. Where a reader has told us who they are directly, we now use that over a match inferred from their IP address. Some numbers in your "Audience" dashboard from before 12 August 2026 may look different as a result.
What's changed
Turtl uses more than one signal to work out which company a contact belongs to.
Some signals come from the contact directly. They signed in with a work email, filled in a form, or arrived through a link tied to a known contact in your CRM.
Others are inferred. When a contact hasn't identified themselves, we look up the IP address behind the visit to estimate which company they're from. This is how account identification works across the industry, and it's what makes anonymous traffic visible at all.
IP lookup is an estimate, not a certainty. A contact on a VPN, working from home, behind a corporate proxy, or sitting on an agency or parent-company IP range can resolve to a company that isn't theirs. That's a limit of the method rather than a fault in the data.
So the two kinds of signal don't always agree. Until now, an IP-based match could sit on top of a contact we already knew by name. From 12 August, direct identification wins. If a contact signed in as someone@acme.com, they're reported under Acme, whatever their IP address suggests.
Why this matters
Account data is only worth acting on if the account is right.
If a known contact is filed under the wrong company, three things break. Your account intent scores are calculated against the wrong account. Your ABM reporting attributes engagement to a company that wasn't reading, and anyone picking up the follow-up is working from a bad list.
This change means the accounts you see are the accounts you can act on.
How we identify accounts now
We check signals in this order and use the first one we find:
Signed in: The reader logged in via SSO with a work email address.
Submitted a form: The reader completed a Turtl form, or is matched to a known contact in your connected CRM.
Arrived via a lead capture URL: The link the reader followed was tied to a specific contact.
IP-based match: No direct identification, so we estimate the likely company from the IP address behind the visit.
Unknown: No signal strong enough to attribute with confidence.
IP-based matching still does most of the work. The majority of readers never identify themselves directly, and for all of them step 4 is what puts an account on your dashboard. What's changed is only what happens when steps 1 to 3 already give us a definitive answer.
Personal email domains (gmail.com, outlook.com, yahoo.com, icloud.com, hotmail.com) aren't treated as company identifiers, so a reader who signs up with a personal address won't be filed under a company on that basis alone.
Why IP matching still come first when content is served
There are two separate moments here, and they have different information available.
When someone opens your content: Personalization has to resolve an account immediately, before the page renders. At that point, the reader hasn't signed in or submitted anything. The IP lookup is the only signal available, so it's what Dynamic Personalization uses to decide what to show.
When you look at your dashboard: We know more. The reader may have gone on to sign in or complete a form, which tells us definitively who they are. Reporting uses that.
So IP matching isn't being replaced. It's still what makes real-time personalization possible. Reporting has simply stopped ignoring the better information that arrives later.
Where personalization and reporting can disagree
Because the two resolve at different moments, they can occasionally point at different companies.
If a reader's IP suggested one company, they were served personalized content for that company. If they then signed in with an email from a different company, the read is now reported under the second. Your "Personalization" tab shows which version was served. Your "Audience" tab shows the account we've since confirmed.
Neither number is wrong. Each reflects what was known at the time. If you're reconciling the two tabs and they don't line up, this is usually why.
What you might see change
Data from before 12 August 2026 has been reprocessed, so historic numbers may not match reports you exported or screenshots you took previously.
Depending on your content and audience, you may see:
Some accounts appear that weren't there before: Reads that sat under one company have moved to the company the reader actually belongs to.
Some account read counts go down: If reads were previously grouped under a single account, they may now be spread across several.
Account intent scores shift: Intent is calculated per account, so reassigned reads change the underlying counts.
Little or no change at all: If most of your readers identify themselves directly, or most are anonymous, your numbers will look much the same.
Total reads and total contacts are unaffected. This change is about which account a read is attributed to, not whether it's counted.
What hasn't changed
How reads, unique reads, and engagement time are measured
Contact-level reporting
Your "Revenue" and "Content" tabs
How anonymous readers are identified when there's no direct signal, which is still IP-based
If an account still looks wrong
Account matching is never perfect, and IP-based matches remain a best estimate. If you're seeing an account you don't recognize, or a reader you'd expect to see attributed differently:
Check the "Contacts" tab to see whether the reader was identified directly or matched by IP address.
Confirm the reader's email domain matches the company you'd expect.
If it still looks wrong, contact support with the account name, the date range, and the Doc involved.
Getting more accounts identified
The more readers who identify themselves directly, the more accurate your account reporting becomes. The three most effective steps are:
Use lead capture URLs when sending Turtl content through email or your marketing platform.
Connect your CRM so known contacts are matched automatically.
Place a form early in high-value content rather than at the end.