Do we need a customer data platform?

Not necessarily. A customer data platform collects behavioural and profile data, resolves identities and sends audiences to marketing tools. It suits businesses with high-volume, multichannel marketing needs. Many businesses get most of the value by integrating CRM, ecommerce and support systems directly, with one system acting as the source of truth for customer records.

Does integrating customer data make it compliant to use?

No. Combining data does not change the purposes for which it was collected. If your business is covered by the Privacy Act, using personal information for a purpose other than the one it was collected for generally needs consent or another exception, and direct marketing has its own rules. Check purposes and consent before using combined data, and get advice for new uses.

How do you match customers across systems?

Use the strongest shared identifiers first, such as a customer number or a verified email address, then combine weaker attributes like name, phone and address with rules or scoring. Send uncertain matches to people, never merge on weak evidence, and keep a record of which source records make up each customer so merges can be reversed.

How do we keep unsubscribe and consent consistent?

Treat consent as data with its own source of truth. Record what the person agreed to, through which channel and when, and propagate withdrawals to every system that sends messages. Under the Spam Act, unsubscribe requests must be honoured within five working days, so syncing them once a week is not good enough.

Who should own customer data integration?

A named business owner should decide definitions, purposes and access, and a technical owner should run the integrations, monitoring and data quality. Without both, duplicate records, conflicting values and unclear permissions creep back. Write down which system owns each field and review it when systems change.

Is a consent banner enough to comply with Australian rules?

No. A banner records a choice, but compliance depends on what data you collect, how you use and share it, whether withdrawals reach every system, and, for marketing messages, consent and unsubscribe under the Spam Act. Integrate consent across systems and keep an audit trail.

Web Development8 min read

Customer Data Integration in Australia: A Single Customer View Without the Risks

How Australian businesses integrate customer data across CRM, ecommerce and support: identity resolution, sync, data quality, consent, privacy and ownership.

What does good customer data integration look like?

Good customer data integration gives each team an accurate, consistent view of a customer by matching records across systems, syncing changes reliably, fixing data quality at the source, and controlling who can use which data for which purposes. It is not the same as buying a customer data platform, and combining data does not make new uses of it lawful: in Australia, the Privacy Act's purpose, direct marketing and security principles, and the Spam Act, still apply.

This guide is for operations, marketing and technology leaders connecting CRM, ecommerce, support, billing and marketing systems. It covers identity resolution, synchronisation, data quality, duplicates, ownership, consent, access control, event pipelines and when a CDP is worth considering.

For CRM choices, see custom vs off-the-shelf CRM; for integration mechanics, API integration for Australian businesses; for ecommerce specifics, ecommerce CRM integration and ecommerce privacy. Nothing here is legal advice.

Key takeaways

Name a source of truth for each customer field; most problems come from two systems claiming the same field.
Match on strong identifiers first, review uncertain matches, and keep merges reversible.
Fix data quality where data is captured, not only in the integration.
Treat consent as data and propagate withdrawals quickly.
Combining data does not authorise new uses; check purposes under the Privacy Act.
Limit access to combined profiles; they are attractive to attackers and broaden breach impact.
Choose integration or a CDP based on use cases, not on tooling fashion.

Integration vs customer data platform

	Direct integration	Customer data platform (CDP)
Main purpose	Keep operational systems consistent	Unify behavioural and profile data for marketing and personalisation
Typical sources	CRM, ecommerce, support, billing	Web and app events plus operational systems
Strength	Simpler, fits most operational needs	Identity resolution at scale, audience building
Risks	Point-to-point sprawl if unmanaged	Cost, complexity, broad data collection
Fits when	Teams need consistent records and history	High-volume multichannel marketing with clear purposes

Ownership: who owns which field?

Before building anything, write a field ownership table. For example, the billing system owns billing address and payment status; the CRM owns account owner and lifecycle stage; the ecommerce platform owns order history; the email platform holds send history but not the master consent record. Each integration then knows which direction data flows and which value wins in a conflict.

Pro tip

Our recommendation: add a 'last updated by system' and timestamp to synced fields. When two systems disagree, you can see which change came last and from where, which makes most sync bugs easy to diagnose.

Identity resolution and duplicates

Use strong identifiers first: customer number, account ID, verified email, ABN for business customers.
Use weaker attributes (name, phone, address) only in combination, with rules or scoring.
Normalise before matching: case, whitespace, phone formats, Australian address formats.
Send uncertain matches to a review queue; never auto-merge on weak evidence.
Keep links to every source record so merges can be audited and reversed.
Handle businesses and people separately: one person can belong to several organisations.

Synchronisation patterns

Use events or webhooks for changes that matter quickly, such as consent withdrawals, new orders and status changes, and scheduled syncs for bulk or low-urgency data. Make updates idempotent, handle out-of-order events with timestamps, retry with backoff, and alert when a sync stops. Reconcile periodically by comparing counts and samples across systems. Our API integration guide covers retries, queues and monitoring, and event-driven architecture covers event pipelines.

Data quality

Most data quality problems are created at capture: free-text fields, optional fields that should be required, inconsistent picklists, staff creating new records instead of searching. Fix forms and processes first, validate formats (email, phone, ABN, postcode), and report quality metrics such as duplicate rate and completeness by source. See workflow digitisation for structured capture.

Purpose. If your business is covered by the Privacy Act, APP 6 generally limits the use and disclosure of personal information to the purpose for which it was collected, unless an exception applies, such as consent or a related secondary purpose the person would reasonably expect (OAIC). Combining support records with marketing data, for example, may be a new purpose. APP 7 sets rules for direct marketing, and APP 3 limits collection to what is reasonably necessary.

Consent and unsubscribes. Under the Spam Act, commercial electronic messages generally need consent, and unsubscribe requests must be honoured within five working days (ACMA). Store consent with its source and time, and push withdrawals to every sending system promptly.

Security and breach scope. Combined profiles concentrate personal information, so a breach affects more data. Restrict access by role, log access to full profiles, keep sensitive information out of marketing tools, and assess overseas data flows under APP 8. The OAIC received 1,205 data breach notifications in 2025 (OAIC).

Tracking data. If behavioural data from websites or apps joins customer profiles, apply the OAIC's guidance on tracking pixels; see product analytics implementation.

A phased approach

Phase 1: inventory systems and fields (see data migration planning for profiling techniques), write the ownership table, agree definitions and purposes.
Phase 2: integrate the two systems with the most valuable shared records (often CRM and ecommerce or billing).
Phase 3: add identity resolution with review queues; clean historical duplicates.
Phase 4: propagate consent across sending tools; add monitoring and reconciliation.
Phase 5: consider a CDP only if marketing use cases justify it, with purposes documented. Reporting on the combined data is covered in business intelligence dashboards.

Hypothetical example: a homewares retailer

This example is hypothetical. A homewares retailer with stores and an online shop has customers in its ecommerce platform, a loyalty app, its POS system and a support tool, with different emails and phone formats in each. Marketing sends to people who unsubscribed in another tool. (Retention use cases are covered in retention technology.)

The retailer names the ecommerce platform as the source of truth for customer profiles and the email platform as the source for marketing consent, with withdrawals pushed to every sending tool within minutes. Store and loyalty records are matched on verified email or loyalty number, with uncertain matches reviewed by the customer service team. Support notes stay in the support tool and are not copied into marketing profiles. A CDP is deferred until the team has documented marketing use cases.

Common mistakes

Two systems both writing the same field with no rule for conflicts.
Automatic merges on name and postcode.
Weekly unsubscribe syncs.
Buying a CDP before defining use cases and purposes.
Copying support notes or sensitive data into marketing tools.
No owner, so quality drifts after the project ends.

Consent works only if every system that uses customer data respects the same, current preferences.

A single source of truth for consent and preferences, by channel and purpose, with source and timestamp.
A preference centre customers can use to change choices at any time.
Real-time or near real-time propagation of withdrawals to email, SMS, advertising audiences and CRM.
An audit trail of consent changes for complaints and regulator questions.
Consent banners are not enough on their own: what matters is how data is actually collected, used and shared under the Privacy Act and Spam Act.
See privacy by design.

Sources

Privacy: OAIC, APP 6; OAIC, APP 8; OAIC, NDB statistics 2025.

Messages: ACMA, avoid sending spam.

Tables, checklists and example are ours. Nothing here is legal advice or ZSpace client data.

Conclusion

Customer data integration pays off when every field has an owner, matches are careful and reversible, consent travels with the data, and access to combined profiles is controlled. Start with direct integrations between the systems that matter most, fix quality at the source, check purposes before new uses, and consider a CDP only when clear use cases justify it. For choosing tools, see CDP vs CRM.

Customer data in too many places?

ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on data integrations, ecommerce and CRM connections and automation. If it would help to map your customer data, we are happy to talk it through.

Start a Project

FAQ

Common questions.

Customer data integration connects the systems that hold customer information, such as CRM, ecommerce, support, billing and marketing tools, so records are matched, kept in sync and usable together. The goal is a reliable view of each customer and consistent data across systems, with clear ownership of each field and controls over who can use the data for what.