A practical guide for journals, societies and university presses that want one view of each reader, author and member, without a two-year IT project.
Most publishers and societies already own everything they need to personalize: submission records, peer review history, membership status, event registrations, email engagement and article usage. The problem is that those records live in five or six systems that have never been introduced to each other. Customer data integration is the discipline of connecting them so that one researcher shows up as one person. This guide explains what it means in a scholarly publishing context, which systems to connect first, how to solve the identity problem, and the governance rules to write down before you connect anything.
What is customer data integration?
Customer data integration (CDI) is the process of combining customer information from separate systems into a single, consistent, accurate view that every team and tool can use. TechTarget's definition frames it as the foundation for a "single customer view", and in commerce that usually means merging CRM, e-commerce and support data. In scholarly publishing the systems are different but the goal is the same: the person who submitted a manuscript in March, reviewed two papers in June, renewed a society membership in September and opened your table-of-contents alert last Tuesday should be recognized as one researcher, not four partial profiles.
CDI is not the same thing as buying a customer data platform. A CDP is one tool that can help with integration; the integration itself is a set of decisions about identifiers, matching rules, permitted uses and which fields are allowed to flow between systems. Those decisions matter more than the software, which is why we argued in Before the Algorithm that connected, well-governed data beats any model you could run on top of fragmented data.
Why publishers and societies need it now
Three pressures are converging. First, personalization expectations have risen: researchers get relevance from every consumer product they use and increasingly expect it from the journals and societies they belong to (we covered what that looks like in practice in What Meaningful Personalization Actually Looks Like in Scholarly Publishing). Second, AI tools are only as good as their inputs. Gartner found that 63% of organizations either lack or are unsure they have the data management practices needed for AI, and predicts that through 2026 organizations will abandon 60% of AI projects that are not supported by AI-ready data. Third, the industry is consolidating and re-platforming, as October's news made clear, and every ownership or platform change is a moment when disconnected reader data turns into lost relationships.
The customer data integration process, step by step
You do not need to unify everything at once. The organizations that succeed treat CDI as a sequence of small, measurable connections rather than a single big-bang migration. Here is the process we recommend.
Step 1: Inventory every system that holds reader data
Start with a simple spreadsheet. For each system, record the owner, the identifier it uses for a person, the consent basis under which the data was collected, how often it refreshes, and what it uniquely knows. A typical publisher or society has at least these six:
- Submission and peer review system (knows authors, reviewers, editors, subject areas, decisions)
- Membership database or AMS/CRM (knows join date, renewal status, section memberships, dues)
- Email platform (knows subscriptions, sends, opens, clicks, bounces)
- Web analytics and content platform (knows article views, downloads, time on page)
- Events registration (knows attendance, sessions, abstracts)
- Access and entitlements (knows institutional affiliations and subscriptions)
The inventory alone usually surfaces the first surprise: the same person has three different email addresses across those systems.
Step 2: Choose the identifier that will anchor matching
Researcher identity is harder to resolve than consumer identity. Academics change institutions and email addresses several times across a career, publish under name variants and transliterations, and register for events with personal addresses. Fuzzy name matching produces both false merges and missed matches. The reliable anchor is a persistent identifier. ORCID passed 10 million registered iDs in 2020 and has kept growing since, most researchers who publish already have one, and it survives every change of employer and email. Capture ORCID iDs at submission, membership renewal and event registration, use a verified email address as the secondary key, and treat name matching as a last resort that a human reviews.
Step 3: Write the governance rules before you connect anything
Connecting systems is a technical task; deciding what may cross between them is a governance task, and in scholarly publishing it carries unusual weight. Three questions need documented answers:
- Who owns the reader relationship? A society journal published with a commercial partner often has contractual limits on who controls subscriber, author and usage data.
- What may each field be used for? Data collected for one purpose cannot automatically be reused for another, under GDPR and under the norms of scholarly communication. Peer review activity is the clearest case: the fact that someone reviewed a specific manuscript is confidential and must never inform marketing.
- Is any of this written down? Rules that live in long-serving staff members' heads cannot be audited or applied by a new tool. This is the same discipline that separates email compliance software built for regulated industries from a general-purpose sender.
A good integration spec therefore lists not only which systems connect, but which fields are allowed to flow, in which direction, and which are explicitly blocked.
Step 4: Connect the first two systems
Score each candidate pairing on four criteria: a shared reliable identifier, the value of the combined insight, how clearly the use is permitted, and technical feasibility. For most publishers the answer is email plus web analytics. Tracked links already bridge the two, the consent context is aligned, and the result immediately separates readers who clicked from readers who actually read, which matters more every year as open rates become less reliable. The second connection is usually email plus the membership database, so that renewals, lapsed members and new joiners stop receiving the same message (see why members and non-members should never get the same email). Submission system to CRM is valuable but governance-heavy, so it comes later.
Step 5: Run one pilot and measure it
Pick a single use case that the first connection makes possible, such as a renewal sequence segmented by engagement, or a topic-based alert driven by reading behavior rather than declared interests. Define the baseline before you launch, run it for one cycle, and compare engagement and conversion against the unsegmented version. A measured win funds the next connection; an unmeasured one does not.
Customer data integration best practices for publishers
- Integrate at the field level, not the system level. "Connect the CRM to email" is not a spec. "Send membership status, section and renewal date to the email platform; never send reviewer assignments" is.
- Prefer real-time sync for status fields and batch sync for history. Membership status should update the moment someone renews; article reading history can arrive nightly.
- Keep one system of record per field. If renewal date lives in the AMS, the email platform reads it and never writes it.
- Log consent with the record. Store the source and date of consent next to the email address so every downstream use can be justified.
- Audit matches quarterly. Sample merged records and check for false merges, especially among common names and shared institutional addresses.
- Measure something the integration makes possible. If a connection does not change a segment, a send or a decision, question why it exists.
Customer data integration tools: what to look for
Publishers rarely need an enterprise CDI suite. What they need is an email platform with native, two-way integrations to the systems they already run, so that the integration work is configuration rather than custom development. When evaluating customer data integration software, look for pre-built connectors to your AMS or CRM and your web analytics, field-level mapping with the ability to block fields, support for ORCID or another custom identifier as a match key, consent and suppression handling that survives the sync, and an audit trail of what changed and when. iPost's integrations and publishing platform solutions were built around exactly this pairing of email, analytics and membership data; if you want to see how the first connection works in practice, talk to us about a pilot.
FAQ: Customer Data Integration for Publishers
What is customer data integration in simple terms?
Combining the records that separate systems hold about the same person into one consistent, accurate profile that every team and tool can use.
What is the difference between customer data integration and a customer data platform?
Customer data integration is the practice: identifiers, matching rules, permitted uses and field-level mapping. A customer data platform (CDP) is one category of software that can perform parts of it. You can integrate well without a CDP and badly with one.
Which systems should a publisher connect first?
Email and web analytics, in most cases, followed by email and the membership database or CRM. Submission systems come later because peer review data needs the strictest governance.
Why is ORCID important for customer data integration?
Because it is a persistent identifier that survives changes of institution, email address and name format, which makes it the most reliable key for matching one researcher across systems.
How long does customer data integration take?
The first connection, such as email to analytics, is typically weeks when native connectors exist. The inventory and governance work should come first and usually takes longer than the technical connection.
Sources
- TechTarget. What is customer data integration (CDI)?
- Gartner (26 February 2025). Lack of AI-Ready Data Puts AI Projects at Risk.
- InfoDOCKET (20 November 2020). ORCID reaches 10 million registered iDs.
