We unify the customer data held on your website, e-commerce platform, CRM, call records and in-store tills under a single identity. Duplicate records are matched, segments are generated by rule, consent status travels with every record, and segments are pushed to channels in a controlled way. The aim is not another report, but a working customer view that the channels can use every day.
In most companies the same customer lives as more than one record. They are registered on the e-commerce site under one email address, they called the contact centre from a different number, in store they had the invoice made out in their spouse's name, and in accounting they sit as a trading account under a company title. None of these records is wrong; each is correct from the point of view of its own system. But no system knows that these four records belong to the same person. In practice it looks like this: a customer who bought in store last week receives a discount message for the same product, a customer who has been buying regularly for years falls into the new-customer campaign, and someone in the middle of a return is met with a satisfaction survey the next day. What grates is not the message itself, but the fact that the company clearly does not know its customer.
In most businesses this problem is managed with stopgaps. Before a campaign the lists are exported separately, merged by hand in spreadsheets, duplicate rows are picked out by eye and a one-off list comes out at the end. That list starts going stale the moment it is sent; the same work is done from scratch for the next campaign. What is more, consent information is usually lost along the way: who gave permission for which channel and who opted out does not travel with the list. And there is this: when the person who does the merging leaves, the method goes with them, because the rules are not written down anywhere. The real problem here is not that the team is careless, it is that the work cannot be sustained by hand. The responses and complaints that follow a campaign are not recorded in the same file either, so they never carry over to the next list.
A customer data platform (CDP) turns this merging from a job repeated for every campaign into a system that runs continuously. Records coming from the website, the e-commerce platform, CRM, call records, in-store tills and dealer systems are gathered into a single customer profile; records belonging to the same person are merged with matching rules built on fields such as email, phone, tax number and order information. Behaviour is added on top of the profile: when they bought what, which category they looked at, how many support requests they opened, how many days have passed since their last purchase. Segments are then tied to rules and update themselves; a definition such as customers who have not bought in the last ninety days, who have bought at least three times before and who hold an email consent is recalculated every morning. The campaign list is no longer prepared; it is already there in the system.
Let us also separate out a concept that is often confused. A data management platform (DMP) is a structure used mainly for ad targeting and working largely with anonymous, short-lived cookie data; a CDP works with the identified, persistent customer data that you own. As third-party cookies have been restricted in browsers, the classic use of the DMP has narrowed and the weight has shifted to your own data; today the audiences sent to advertising platforms are mostly produced from consented lists in the CDP. Let us draw the line at the outset: the system we build does not match with one hundred per cent accuracy. Records whose identity data is weak are left unmerged, and that is reported with an acceptable margin of error; silently merging doubtful matches is more damaging than leaving them apart. Nor is a customer without consent sent to a marketing channel in any segment; consent status is a mandatory field carried by the profile.
Companies that see the same customer separately through the store, the website, marketplaces and the contact centre. When a separate list is kept per channel, campaigns collide, the same person is counted more than once and the customer value calculation does not reflect reality. A unified profile makes that picture visible in one place for the first time. Channel-level reports can also be added together for the first time.
Even when the sale happens at the dealer, warranty registration, service requests, campaign participation and website behaviour leave end-user data with the manufacturer. This data usually sits scattered across systems that know nothing about each other. Once it is gathered into a single profile, it becomes possible to communicate with the end user without damaging the dealer relationship. The question of which end users sit in which dealer's territory can also be answered for the first time.
Places where the same customer appears on three separate cards, where repeats in lists are weeded out by hand, and where nobody knows which contact detail is current. The first gain here is not in the campaign but in the disappearance of the time spent cleaning data and in reports becoming trustworthy for the first time. Reaching the same person under two different names looks like a small mistake from the outside, but it erodes trust directly.
If the marketing list and the sales customer records do not recognise each other, the representative does not know which campaign went to their customer, and marketing cannot see which customer is at the meeting stage. A shared profile lets both teams look at the same record and stops the two lines of communication cutting across each other. The handover point becomes clear too: what information sales is to continue with, from the point where marketing leaves off, sits in the record.
Website and mobile app events, the e-commerce platform, CRM, contact centre, in-store tills, the dealer portal and the trading account records on the ERP side are collected through regular flows. Where the source has an API we connect directly; where it does not, we connect at database or file level. The source systems stay where they are; the CDP does not replace them, it builds a reading and merging layer on top of them.
Records belonging to the same person are matched through fields such as email, phone, tax number and customer number. Deterministic rules are used for fields that match exactly, and fuzzy matching for spelling differences and missing information. Low-confidence matches are not merged automatically; they go into a separate queue for review. Every merge decision is recorded in a way that can be undone.
Orders, returns, support requests, site visits, campaign interactions and in-store purchases accumulate beneath the profile in chronological order. That way the answer to who is this customer is not a static card but a history you can write rules against. Which events are collected is decided together during discovery; rather than collecting everything, we collect what will be used. The events collected are read from the same source both in the segment rule and on the customer card.
Segments are defined as rules rather than one-off lists and are recalculated at a set frequency. Purchase frequency, last purchase date, spend band, category interest and consent status can be used together. When a customer stops meeting the rule they drop out of the segment by themselves; updating the list by hand disappears entirely. Segment definitions are stored with version tracking; which campaign ran on which version of a rule can be found afterwards.
When permission was given for which channel and with what wording, and the date and source if it was withdrawn, are held on the profile. When a segment is pushed to a channel, the consent filter is applied as a matter of course; a record without consent never enters the export file. These records can be used as evidence on the KVKK (Turkish data protection law) side, while the legal assessment belongs to your adviser. The versions of the consent texts are kept as well, because what a person agreed to can change over time.
The segments produced are pushed to marketing automation, the contact centre screen, the e-commerce site and advertising platforms. On the advertising side, consented customer lists can be used for targeting or for exclusion; keeping an existing customer out of a new-customer campaign is the first concrete gain in most companies. Every push is logged. The export format is converted into the structure the channel expects; the step of preparing files by hand disappears.
How many profiles were merged, how many records were left unmatched, and which field arrives systematically empty from which source: all of this is monitored on a dashboard. Data quality is not a job you clean up once and finish; unless the error at source is fixed, the dirt comes back. The dashboard shows which system and which form needs correcting. That way the improvement is made where the data is produced, not on the side that uses it. The measures are compared over time, so improvement or deterioration becomes visible.
We map out which systems hold customer data, in which fields and how completely they are filled in. At the same time we clarify which questions you want answered; collecting data that will not be used has a cost of its own. In this step the duplication rate is measured, so the size of the job is discussed with a number rather than a guess. The output of discovery is a written plan showing which source will be connected in which order.
Which fields count as identity, which matches will be merged automatically and which will go to a person for approval is decided in writing. The rules are tested together on real sample records. If this step is skipped, the system either merges far too little or merges different people; both prove expensive later.
Source systems are connected, historical data is transferred and profiles are formed. During this period nothing is pushed to channels yet; the goal is to see that the profiles and the event history are forming correctly. We sample known customers and compare the result with your team. Depending on the number of sources, this step takes four to eight weeks in most projects.
We start with a limited number of segments and push them to a single channel. Once the result is verified, the number of channels and segments is increased. The consent filter is mandatory from day one; pushes are logged, so which list went where and when can be shown afterwards. If a push fails, the flow is stopped; a list that has gone out half way is not silently completed.
How segment rules are written, how the match queue is reviewed and how the data quality dashboard is read are passed on to your team and left in writing. When a new source system is added, we bring it into the pipeline. The system is monitored in production; a breakage on the source side is caught before it spreads silently. The moment your team can write a segment rule themselves, the job leaves us and stays with you. Maintenance covers source changes and requests for new fields.
CRM runs the sales and relationship process: who called, which quote is at which stage, what the representative did. A CDP unifies the customer records held in different systems under a single identity and generates segments from that unified profile. The CRM is usually both a source and a destination for the CDP; it feeds the profile with its records and takes the resulting segment back. We do not replace your existing CRM, we build a data layer beside it.
Not a duplicate, a neighbour. A data warehouse and BI are built to analyse history, report and support decisions; the output of a CDP is not a report but the live segments the channels use every day. In most installations they run alongside each other on the same data infrastructure. There is a difference from master data management (MDM) too: MDM deduplicates all of an organisation's master records under governance rules, while a CDP focuses on the customer side and on marketing use.
Yes, that risk is real and we design for it. Doubtful matches are not merged automatically, they are left for human approval; merge operations are recorded in a way that can be undone. Shared email addresses, family members giving the same phone number and corporate shared addresses are known traps and are handled separately in the rules. We do not promise one hundred per cent accuracy; we aim for a margin of error that can be measured and corrected.
Both are outside the scope of this page. The CDP determines who is in which segment; writing the message, building the flow and sending it are the job of the marketing automation side and are a separate module. On the KVKK (Turkish data protection law) side it holds the consent records, logs the pushes and produces evidence; but which processing rests on which legal basis, what the privacy notice says and whether consent is valid are matters of legal assessment. Your lawyer does that, not the software.
Probably not, and we say so at the outset. If you work with a small number of customers, a single sales channel and one system, building a CDP brings cost and a maintenance burden; tidying up the fields inside your CRM is often enough. A CDP makes sense where there are several channels and at least three systems that do not know each other, and where duplication has become a measurable problem. We take that measurement during discovery, and if it is not needed we tell you it is not needed.
Regularly running data pipelines from the source systems; a profile structure that unifies records under a single identity and queues matches that have not been reviewed; event history; rule-based segments that update themselves; channel pushes that apply consent status as a mandatory filter; a data quality and matching dashboard. The documentation of the matching rules and the handover notes are part of the delivery too. The source code and the data that accumulates belong to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We turn email, SMS and WhatsApp messages from announcements sent one at a time into flows that run themselves according to what the customer does. Abandoned basket, welcome, win-back and post-purchase flows are built; people who show interest are scored and handed over to the sales team. Consent and sending discipline are built into the flow itself.
Details →We build a learning management system (LMS) that brings together, in one place, the training catalogue, who is required to take which course, who has completed it and when a certificate expires. When an audit asks for the record of your health and safety and quality training, it comes out on a single screen rather than after hours of searching.
Details →We build a system that ties the company goal to team and individual goals and bases the end-of-period review on records rather than memory. Goal management runs on OKR and individual assessment on a performance management system (PMS); we keep the two side by side on the same platform without mixing them up.
Details →We do not replace Logo, Mikro or Netsis (the accounting packages in common use in Türkiye). We build a finance layer that gathers current accounts, banks, cash, cheques and promissory notes, expenses and cash flow alongside your accounting package, and puts collection, payment and approval processes on rules. The record is still kept in accounting; visibility and process run in this layer.
Details →We move the budget out of Excel files and into a system that is versioned, has a named owner and is compared with actuals automatically. When the month closes, the variance report is not put together by hand; the reason for the variance is recorded, the forecast is updated and the management pack is produced from the same numbers. The goal is not more reports, but seeing where you stand against target in a single figure nobody disputes.
Details →On legacy systems with no API, we build software robots that take over the repetitive steps a person performs on screen. The robot runs under its own user account and on a schedule; when something unexpected happens it does not guess, it stops and hands the job over to a person along with a screenshot.
Details →
