KVKK & Marketing Data Guide: Compliance for Attribution Pipelines

Introduction: The Marketing Team's Quiet Conflict

In 2026, the marketing teams of Turkish brands sit in the middle of a quiet conflict. On one side is the cookie-plus-third-party-pixel chain that last-click attribution and performance marketing have built up over years; on the other side are KVKK audits, cookie-compliance rulings, and rising consumer awareness about data. When the CMO tells the CFO "our ROAS hit 4," and legal counsel asks "do you have a chain of explicit consent for the user IDs flowing from GA4 to Meta CAPI?" — the meeting drops into a tense silence.

This post was written to fill that silence with good questions. It explains, at a practical level, why aggregate-data attribution methods like Marketing Mix Modelling (MMM) align naturally with KVKK (Turkey's data protection law, similar to GDPR), what KVKK Article 12 demands of a marketing team, what counts as "PII," the legal distinction between explicit consent and contractual obligation, how to respect GA Consent Mode V2 signals, and how to process a deletion request within 48 hours. This post is not binding legal advice — please do not skip the disclaimer at the end.

What Is KVKK Article 12?

Article 12 of the Personal Data Protection Law (KVKK) is titled "Obligations for Data Security." It describes the technical and administrative measures that the data controller (i.e., the brand) must take when processing personal data. In a marketing context, those obligations become concrete:

• Data flow records — what data came from where, went where, processed for what purpose. A modern MMM SaaS must produce these automatically; manual documentation is indefensible.
• Privacy notice — the user must be informed in writing of what type of data is processed, for what purpose, for how long, and shared with whom. Squeezing this into a cookie banner is not enough; a separate KVKK privacy notice is required.
• Explicit consent vs. contractual obligation — is the data processed for marketing analytics part of the user contract (e.g., "to track your orders" inside a customer panel), or does it require explicit consent (e.g., creating a segment for an email send)? If you set this legal basis wrong, a KVKK audit will hit you with "consent not collected."
• Technical measures — encryption (in-transit + at-rest), access control, audit logs, database-level tenant isolation. "We use the cloud securely" is not enough; you must be able to evidence specific controls.
• Administrative measures — contracts with data processors (vendors), employee training, breach notification procedures, periodic audits.

The practical meaning: in a KVKK audit, you must answer line by line "what data goes into your MMM, how is it protected, who can access it, how long is it retained, how many hours does it take to honour a deletion request?" MMMytics is designed as a product where these answers are ready: a KVKK Article 12 record is automatically generated for each data submission, written to the audit log, and a deletion request is bound to a 48-hour SLA in a single click.

Marketing Data Classification

The most critical step in KVKK compliance is clearly seeing which data counts as "personal data." In a marketing context, data falls into roughly three categories:

1. Anonymous aggregate data. This category includes total impressions, total clicks, total GRPs, weekly channel spend — fully aggregated numbers that do not identify any individual. Under KVKK, this is not "personal data" — it cannot be linked back to a person. MMM works exactly with this category. "We received 1.2 million impressions on TV last week" enters the model; "who saw these impressions" does not. This is MMM's structural KVKK alignment, not a certificate added afterwards.

2. Pseudonymous data. This category covers user IDs (uid), client IDs (cid), advertising IDs (gaid/idfa), hashed emails — data that can be re-linked to a person but does not directly carry identity. KVKK treats this as "personal data" because, while not identifying alone, it identifies the individual when joined with other data. GA4 operates in this category; Meta CAPI and Conversions API ask for hashed email + hashed phone. This data does not enter MMM; there is no need for it to. If a marketing team plans to connect raw GA4 event exports to MMM, the aggregation step is mandatory: collapse to daily/weekly total impressions, drop the uids.

3. Personal data (PII). Data that directly identifies an individual: name, plain-text email, plain-text phone, national ID, address, date of birth. MMMytics does not store PII. Beyond that, MMMytics runs a pre-upload PII detection layer: the Data Hub upload pipeline detects national-ID patterns, Turkish name-surname patterns, email + phone formats in CSV files, and rejects uploads that contain PII rows. This is the concrete form of KVKK Article 12's "technical measures" obligation — the vendor cannot accidentally take in PII.

When transferring data from platforms like GA4 and Meta CAPI to MMM, the practical rule is: end-to-end aggregation chain. Do not flow directly from your raw event table to the MMM model; place an aggregation step in between (weekly total, sector + region basis). This is good not only for KVKK but also for model performance: MMM needs signal, not noise.

Data Retention & Residency

KVKK Article 9 binds the cross-border transfer of personal data to strict conditions: explicit consent, an adequacy decision country list, or binding corporate rules. For a SaaS serving the Turkish market, storing data in a US region is practically forbidden — mechanisms like the Cloud Act and FISA mean US regions fail the "adequacy" test.

MMMytics keeps all Turkish customer data in the EU region. Database, cache, file storage, and compute — end-to-end EU region. There is no fallback to a US region; it is impossible by design.

For tenant isolation, database-level tenant isolation is used. Each brand is filtered by its brand_id; an analyst from one brand cannot see another brand's data, and cannot even attempt to (the policy is enforced at the database layer). This is not "we check it in application code" — it is "the database blocks it row by row" — which is more robust and auditable.

There is a CDN nuance: global CDNs can route through the US. The practical distinction here: static assets (logo, JS bundle, CSS) can be served from a global CDN — they contain no personal data. API endpoints and the data plane must always be pinned to the EU region. At MMMytics, API calls go directly to the EU region; the CDN is used only for the marketing site's static content.

Explicit Consent & GA Consent Mode V2

In 2024, Google made Consent Mode V2 mandatory for Europe; without a consent signal, ad data flows are cut. Turkey is not directly EU, but KVKK and the ad ecosystem practice are heading the same way. The marketing team must practically manage 4 consent categories:

• ad_storage — ad cookie consent
• analytics_storage — analytics cookie consent
• ad_user_data — consent to share user data with ad networks
• ad_personalization — personalised advertising consent

The cookie banner must ask for these 4 categories separately; a single "Accept all" button is inconsistent with KVKK (consent must be specific and freely given). When the banner is rejected, GA4, Google Ads, and the Meta Pixel cut the ad data flow; even with analytics_storage denied, consent-less aggregation of impressions continues, but user-level attribution stops.

This is where MMM's KVKK advantage becomes concrete: MMM keeps working in consent-denied mode, because user-level data does not enter the model in the first place. Total impressions, total clicks, total GRPs — these numbers are independent of consent state. When the cookie is rejected, last-click attribution goes blind; MMM keeps seeing. This is the most concrete proof of the claim that "MMM is the attribution standard for the post-cookie world."

Practical recommendation: deploy cookie banner + Consent Mode V2 + MMM together. If the user consents, last-click + MMM hybrid; if not, MMM standalone. In both worlds, you can produce a CFO-ready report.

Right to Deletion & the 48-Hour SLA

KVKK Article 11 gives the user the right to request deletion of their personal data. In a marketing data ecosystem, processing this right looks complex: data may live in 5 places — the database, file storage, cache, CDN edge cache, and vendors (e.g., CRM and email marketing platforms). If even one location retains the data, the deletion request "is not complete."

MMMytics binds this process to a 48-hour SLA:

1. The customer files a deletion request via the panel or the support channel.
2. The request hits the audit log; admin approval registers.
3. Within 48 hours, the deletion flow runs: database row, file storage object, cache key, audit log retention pointer.
4. The deletion-completed record is written back to the audit log (the meta of the deleted data is retained; the data itself is gone).
5. The customer receives an email + dashboard notification.

An important nuance here: audit log retention is not deleted. The record "user X requested deletion on date X, data Y was deleted within X+48h" is retained as a legal obligation — the proof of what you did is what KVKK Article 12 requires. The data itself is gone; the metadata of the action is preserved.

This process works differently for aggregate data. The total weekly impressions feeding the MMM model are not associated with any individual; therefore, a deletion request does not affect the MMM model. A customer can ask "delete user X's data"; they cannot ask "delete the total impression contribution that user X created this week" (in anonymous aggregates, the individual is not defined). This is a feature of MMM that simplifies the deletion step in the KVKK compliance process.

CTA

It is possible to see KVKK compliance not as a barrier in front of marketing measurement, but as a discipline that feeds the model with cleaner data. To see how MMMytics works, Request a Demo; for product and methodology, see the About page; for plans, the Pricing page. For the official regulatory text, kvkk.gov.tr is the reference source.

This post is for general information; for binding legal advice, consult your organisation's KVKK counsel. Final legal text is being prepared with our legal advisors; final contract language is shared during enterprise contract discussions.