تبلیغات بدون کوکی به معنای حذف همه Cookieها یا پایان تبلیغات هدفمند نیست. مسئله واقعی، نامطمئنشدن Signalهایی است که برای شناسایی فرد در چند سایت، ساخت Audience، Remarketing و نسبتدادن Conversion به تبلیغ استفاده میشدند. Browser، تنظیم کاربر، Consent، پلتفرم، دستگاه و قانون قابلاعمال تعیین میکنند چه چیزی قابل مشاهده یا استفاده است؛ نه یک تاریخ جهانی برای «مرگ کوکی».
این راهنما یک Snapshot در ۱۸ مرداد ۱۴۰۵ / ۹ اوت ۲۰۲۶ است. ابتدا وضعیت متناقض اکوسیستم را تصحیح میکند؛ سپس Cookie/Data/Identity/Measurement را جدا، Dependencyها را Audit و یک معماری مقاوم میسازد: Contextual و Owned demand، داده شخص اول Purpose-bound، Preference center، CRM/Lifecycle، Measurement contract، Experiment/Incrementality، Vendor governance و برنامه مهاجرت. هدف جایگزینکردن یک شناسه با شناسه پنهان دیگر نیست؛ هدف تصمیم بازاریابی با داده کمتر، شفافیت بیشتر و عدمقطعیت اندازهگیریشده است.
Snapshot ۲۰۲۶: Chrome کوکی شخص ثالث را سراسری حذف نکرد
بسیاری از مقالهها هنوز میگویند Chrome تا پایان ۲۰۲۴ Third-party cookie را حذف میکند. این برنامه اجرا نشد. Google در بهروزرسانی ۲۲ آوریل ۲۰۲۵ اعلام کرد رویکرد جاریِ انتخاب Cookie در Chrome را حفظ میکند و Prompt مستقل تازهای عرضه نخواهد کرد. سپس در بهروزرسانی ۱۷ اکتبر ۲۰۲۵ بازنشستگی Topics، Protected Audience، Attribution Reporting و چند فناوری دیگر Privacy Sandbox را بهدلیل ارزش مورد انتظار و Adoption پایین اعلام کرد؛ CHIPS و FedCM در میان فناوریهای مورد حمایت باقی ماندند.
| محیط | وضعیت مرتبط | نتیجه برای بازاریاب | اقدام |
|---|---|---|---|
| Chrome عادی | حذف سراسری Third-party cookies کنار گذاشته شد؛ انتخاب/تنظیم کاربر و Policy اثر دارد | نباید فرض کرد Cookie برای همه حاضر یا غایب است | Browser/consent cohort را اندازه بگیرید |
| Chrome Incognito/تنظیم محدود | محدودیتهای شدیدتر ممکن است فعال باشد | Authentication، Embed و Attribution میتوانند متفاوت شوند | Critical flow را بدون 3PC تست کنید |
| Safari/WebKit | Tracking prevention و مسدودسازی Third-party cookie | Cross-site audience و عمر Storage قابل اتکا نیست | از رفتار Shipping شده تست بگیرید |
| Firefox | Total Cookie Protection/partitioning و Tracking protection | State ثالث بین Siteها مشترک فرض نشود | Firefox را Segment مستقل QA کنید |
| WebView/App/Ad platform | Identifier، Consent و Policy مخصوص محیط | Measurement و Reach با Web یکی نیست | Inventory و Contract جدا |
مستند Tracking Prevention در WebKit رفتارهایی مانند Block کامل Third-party cookie در ITP، Partitioning و محدودیتهای دیگر را شرح میدهد. مستند Firefox Total Cookie Protection نیز جداسازی Cookieها برای جلوگیری از Tracking بین سایتها را توضیح میدهد. نتیجه عملی این است: Strategy را روی Browser واحد و وعده Vendor نسازید.
اصطلاحها: Cookieless با Cookie-free فرق دارد
| اصطلاح | تعریف عملی | مثال | برداشت غلط |
|---|---|---|---|
| First-party cookie | Cookie در Context سایت حاضر برای Session/Preference/Measurement | سبد خرید یا Login session | هر استفادهای خودکار مجاز و بیریسک است |
| Third-party cookie | دسترسی Cookie برای Domain ثالث در Context سایت دیگر | Ad-tech در چند Publisher | نوع فایل متفاوتی از Cookie است |
| First-party data | داده رابطه مستقیم Brand با فرد/مشتری | Order، CRM، Support، Preference | «مالکیت» مساوی Consent برای هر Purpose است |
| Zero-party data | اصطلاح بازاریابی برای Preference یا اطلاعات صریحاً اعلامشده | انتخاب دسته علاقهمندی | طبقه قانونی مستقل یا بدون الزام Privacy است |
| Pseudonymous/Hashed | Identifier تبدیلشده اما بالقوه قابل Match/Link | ایمیل SHA-۲۵۶ برای Customer Match | Hash مساوی Anonymous است |
| Contextual | انتخاب آگهی از Context محتوا/صفحه | ابزار کمپ در مقاله کوهپیمایی | همیشه بدون داده یا بدون Risk است |
| Modeled measurement | برآورد بخش مشاهدهنشده با Model | Modeled conversions | عدد مشاهدهشده یا حقیقت قطعی است |
First-party بودن، Location فنی داده را توصیف میکند؛ Purpose، اطلاعرسانی، Consent/مبنای قابلاعمال، Retention، Sharing و حقوق فرد را حل نمیکند. Server-side tagging، CNAME یا Data clean room نیز داده را جادویی Anonymous نمیکنند. راهحل مقاوم از Data governance شروع میشود، نه از دورزدن Browser.
چه چیزی واقعاً در معرض خطر است؟ Use case را Inventory کنید
«Cookie audit» فقط فهرست نام Cookieها نیست. باید Business use case را از UI تا Vendor و Decision دنبال کنید. ممکن است حذف یک Pixel گزارش را تغییر دهد ولی عملیات را نه؛ یا Third-party storage برای Login federation و Embedded checkout حیاتی باشد. Risk هر مورد متفاوت است.
| Use case | Signal/Dependency | Failure بدون Signal | گزینه مقاوم |
|---|---|---|---|
| Session/Cart | First-party cookie/storage | خروج یا سبد گمشده | Same-site secure session؛ QA privacy modes |
| Cross-site remarketing | 3PC/Platform identifier | Audience shrink و frequency loss | Contextual، permissioned CRM، platform-native |
| Frequency capping | شناسه بین Impressionها | نمایش تکراری و آزار | Platform aggregate/first-party cap؛ creative rotation |
| Attribution | Click ID، Cookie، device/account match | Journey ناقص و «Direct» بیشتر | UTM، first-party conversion، experiment/MMM |
| Personalization | Behavior/profile | پیشنهاد عمومیتر | Preference صریح و Session context |
| Affiliate | Click/referral ID و window | Commission dispute | Server reconciliation با anti-fraud و contract |
| Embed/Login | Third-party storage/Federated identity | Flow شکسته | FedCM/Storage Access یا redesign؛ تست دقیق |
برای هر Use case، Criticality، User impact، Revenue dependency، Browser coverage، Vendor، Data categories، Purpose، Consent state، Retention و Exit را ثبت کنید. «چند درصد Conversionها Cookie وابستهاند؟» باید با Test پاسخ داده شود، نه با حدس Vendor.
Audit فنی و داده: از Tag تا Decision
۱. Surface و Technology inventory
- Web، App، WebView، Landing، Subdomain، Checkout، CRM، Call center و Offline sale؛
- Cookie، Local/session storage، IndexedDB، Service worker، Pixel، SDK، Server endpoint، CNAME، URL parameter و Fingerprinting-like signal؛
- Tag manager، Analytics، Ad network، Chat، Video، CAPTCHA، A/B tool و Affiliate؛
- مالک، Contract، Data destination، Region، Retention، Delete/export و Subprocessor.
۲. Data-flow و Purpose ledger
| Field | مثال | چرا لازم است؟ |
|---|---|---|
| Data/Event | purchase، Order ID، amount | تعریف و PII leakage |
| Source→Destination | Checkout→Server→Analytics/Ads | Recipient و cross-border/vendor map |
| Purpose | عملیات سفارش / تحلیل / تبلیغ شخصی | Purposeها را مخلوط نکنید |
| Necessity/Choice | ضروری، Preference، Analytics، Advertising | Default و Consent behavior |
| Identifier | Session ID، Click ID، hashed email | Linkability و Security |
| Retention/Delete | روز/ماه + trigger | Data minimization عملی |
| Owner/Evidence | Marketing Ops + config/log | Accountability و Audit |
Privacy Principles از W3C بر Data minimization، Purpose limitation، Transparency و انتخاب/Withdrawal تأکید میکند. NIST Privacy Framework نیز Privacy risk را در سطح سازمان و Data processing مدیریت میکند. اینها جای بررسی قانون قابلاعمال را نمیگیرند، اما ساختار مناسبی برای Inventory، Risk و Control میدهند.
معماری مقاوم: سه لایه Demand، Relationship و Measurement
| لایه | هدف | دارایی/کانال | Metric | ریسک |
|---|---|---|---|---|
| Demand creation/capture | رسیدن به Audience بدون Identity فردی | Contextual، Search، Content، Publisher و Platform-native | Incremental reach، qualified visit | Context نامناسب، platform dependency |
| Direct relationship | تبدیل Value exchange به Permission و Service | Account، CRM، Preference center، Email/SMS/Loyalty | Opt-in quality، activation، retention | جمعآوری بیشازنیاز و fatigue |
| Measurement/learning | تصمیم بودجه با عدمقطعیت معلوم | Event contract، Order/CRM، Experiment، MMM و Finance | Incrementality، contribution، CAC/LTV | Attribution bias و model opacity |
اگر فقط لایه Relationship بسازید اما Demand جدید نداشته باشید، فهرست موجود را بیشازحد مصرف میکنید. اگر فقط Contextual بخرید اما Outcome را به CRM/Order وصل نکنید، کیفیت را نمیبینید. اگر فقط Attribution platform را دنبال کنید، هر Vendor ممکن است سهم خود را بزرگتر گزارش کند. معماری باید هر سه لایه را با Source of truth مستقل متصل کند.
استراتژی ۱: Contextual و Publisher fit را بازطراحی کنید
Contextual advertising آگهی را براساس Page/Content/Placement انتخاب میکند، نه History فرد در چند سایت. اما «Contextual» لزوماً Privacy-free نیست: Auction، measurement، fraud detection و vendor logs ممکن است داده دیگری پردازش کنند. Data flow را همچنان Audit کنید.
| بعد | سؤال | مثال ایرانی | Guardrail |
|---|---|---|---|
| Semantic fit | موضوع، نیت و مرحله Journey چیست؟ | تبلیغ کفش کوه در راهنمای مسیر، نه خبر حادثه | Negative context و manual review |
| Publisher quality | Audience واقعی، Inventory و fraud control؟ | رسانه تخصصی با شواهد Traffic | Domain/app list و placement report |
| Creative-message match | وعده با Context و Landing همراستاست؟ | قیمت/ارسال متناسب با Offer | Message map و claim evidence |
| Frequency | بدون Cross-site ID چگونه کنترل میشود؟ | Cap در Publisher/platform | Reach-frequency و fatigue proxy |
| Outcome | کیفیت Visit/Lead/Sale چیست؟ | سفارش نگهداشتهشده، نه Click | CRM/Order reconciliation و holdout |
Contextual را با Taxonomy ساده شروع کنید: Include/Exclude، Risk sensitivity، Format و Landing mapping. AI classification میتواند کمک کند، اما Brand safety و زبان فارسی—طعنه، ابهام، خبر حساس و چندمعنایی—به نمونه و Review انسانی نیاز دارد.
استراتژی ۲: Content و Organic را دارایی Demand ببینید
محتوا جایگزین فنی Cookie نیست؛ سازوکاری برای کشف، اعتماد، آموزش و ساخت رابطه مستقیم است. هر Asset باید Problem، Audience، Search/distribution path، Evidence، Next action و Outcome داشته باشد. Lead magnet فقط وقتی ارزش دارد که Exchange روشن باشد و تیم بتواند ارتباط پس از ثبت را مفید نگه دارد.
| Asset | Job | Value exchange | Next step | Measurement |
|---|---|---|---|---|
| راهنمای تصمیم | کاهش ریسک انتخاب | دسترسی آزاد | Calculator/consultation | Qualified progression |
| Template/Checklist | اجرای کار | دانلود؛ ایمیل فقط اگر لازم/شفاف | Onboarding series | Use/activation، نه download خام |
| Webinar/Demo | اعتماد و ارزیابی | زمان و سؤال کاربر | Replay/meeting | Attendance→qualified outcome |
| Tool/Quiz | تشخیص/پیشنهاد | Input کمینه | Result + optional save | Completion/helpfulness |
جزئیات Problem→Evidence→Asset→Distribution→Outcome در راهنمای بازاریابی محتوا آمده است. برای Search نیز راهنمای سئو از Demand تا Outcome را ببینید. Content «رایگان» نیست و نباید فقط برای جمعآوری ایمیل تولید شود.
استراتژی ۳: First-party data را Purpose-bound بسازید
داده شخص اول «طلا» نیست؛ تعهد و بدهی امنیتی/عملیاتی است. فقط دادهای را جمع کنید که Use case، Value برای فرد، کیفیت، Owner و Retention روشن دارد. فهرست بزرگ بدون Permission معتبر، Freshness و Matchability میتواند هزینه و Risk بسازد.
Value exchange و Preference center
| Preference | ارزش برای فرد | Control | Expiration/Refresh |
|---|---|---|---|
| موضوع محتوا | پیام مرتبطتر | انتخاب/حذف دسته | یادآوری دورهای یا behavior conflict |
| کانال | Email/SMS/Push دلخواه | Opt-in مستقل | پس از bounce/عدم تعامل بازبینی |
| Frequency | کاهش مزاحمت | روزانه/هفتگی/فقط مهم | همیشه قابل تغییر |
| شهر/خدمت | موجودی و Offer مرتبط | Manual override | با Context جدید سؤال شود |
| Personalization | ادامه Journey یا Recommendation | Why/disable/reset | Purpose و Model change |
Zero-party data را حقیقت دائمی فرض نکنید؛ Preference تغییر میکند و پاسخ Survey میتواند موقعیتی باشد. Inference را از پاسخ صریح جدا و Confidence/Date ذخیره کنید. عدم ارائه داده اختیاری نباید کاربر را از خدمت نامرتبط محروم کند.
Identity resolution با کمترین Linkability
Identity graph فقط وقتی بسازید که Use case ارزش Risk را داشته باشد. Account ID، Order ID، CRM ID، Device/session و Contact را با Rule و Access جدا مدیریت کنید. Hash کردن ایمیل آن را لزوماً Anonymous نمیکند چون فضای ایمیل قابل Match است. Salt/key، access، transfer، suppression، deletion و Vendor contract اهمیت دارند.
استراتژی ۴: Lifecycle channel را با Permission اداره کنید
Email و SMS کانال مستقیماند، اما «Owned» به معنای حق ارسال نامحدود نیست. Source/Time/Scope رضایت، Proof، Preference، Suppression و Withdrawal را در Consent ledger نگه دارید. Transactional، Service و Promotional message را تفکیک و Frequency را در سطح شخص/کانال کنترل کنید.
| Lifecycle | Trigger | Value | Stop/Guardrail |
|---|---|---|---|
| Welcome | ثبت معتبر | انتظار، Preference و قدم بعد | بدون ثبت/Consent ارسال نشود |
| Activation | Task نیمهتمام | Help متناسب، نه فشار | پس از completion یا refusal متوقف |
| Post-purchase | Order state | رسید، آموزش و Support | تبلیغ را با پیام ضروری مخلوط نکنید |
| Retention | Need/usage signal | یادآوری مرتبط | Frequency cap و inactivity policy |
| Win-back | Dormancy تعریفشده | انتخاب بازگشت یا خروج | محدود، سپس suppression |
راهنمای ایمیل مارکتینگ، رضایت و Deliverability Consent ledger، SPF/DKIM/DMARC، Unsubscribe و Incrementality را عمیقتر پوشش میدهد.
Consent banner ابزار است، نه مجوز یا استراتژی
Consent باید به تصمیم واقعی فرد کمک کند؛ نه اینکه با رنگ، اندازه، تکرار یا مسیر طولانی Reject را پنهان کند. Categoryها، Purpose، Vendor، Retention و اثر Choice را قابل فهم کنید. Grant، deny، withdraw و expiry را End-to-end تست کنید و مطمئن شوید Tagها پیش/پس از انتخاب همان رفتار وعدهدادهشده را دارند.
| State | UI | Tag/Data behavior | Evidence |
|---|---|---|---|
| Unknown | انتخاب روشن و متقارن | Default طبق Policy/Applicability | Network log و CMP record |
| Denied | سایت همچنان برای Purpose غیرضروری قابلاستفاده | Tag/Storage ممنوع Block یا رفتار مستند | No unexpected request/storage |
| Granted | Purpose و تغییر انتخاب روشن | فقط Scope پذیرفتهشده | Timestamp/version/source |
| Withdrawn | به آسانی Grant | توقف آینده + deletion/suppression workflow | Propagation SLA و audit |
| Expired/changed | درخواست متناسب، نه nagging | Policy جدید تا انتخاب معتبر اعمال نشود | Consent version migration |
مستند Google Consent Mode صریحاً میگوید Consent Mode خود Banner یا Widget نیست و Basic/Advanced رفتار متفاوتی در ارسال داده دارند. این محصول جای تعیین قانون، UX سالم یا بررسی Network request را نمیگیرد. برای حذف Dark pattern از Choice architecture، راهنمای طراحی اخلاقی را اجرا کنید.
Activation: First-party audience بدون Governance خطرناک است
Customer Match و ابزارهای مشابه میتوانند Contact consented را با حساب Platform تطبیق دهند؛ اما Eligibility، Policy، Geography، Consent و Data formatting دائماً تغییر میکنند. راهنمای رسمی Consent برای Customer Match برای کاربران EEA سیگنالهای مشخصی را میخواهد و Upload داده بدون Consent لازم را مجاز نمیداند. برای هر Market و Vendor، مستند جاری و Counsel را بررسی کنید.
| Activation option | Fit | Data/Risk | Exit test |
|---|---|---|---|
| Platform-native audience | Reach در همان پلتفرم | Opacity و platform dependency | اگر Account/region محدود شد چه؟ |
| Customer match | Retention/suppression/lookalike مشروط | PII/hash، consent، match و policy | Delete/suppress/export proof |
| Publisher first-party segment | Context+audience ناشر معتبر | تعریف Segment و sharing | Placement/outcome data قابل خروج؟ |
| Universal ID | اکوسیستمهای منتخب | شناسه cross-context و vendor adoption | Coverage واقعی و fallback |
| Data clean room | همکاری داده در Scale کافی | Governance، query leakage، cost | آیا aggregate سادهتر کافی بود؟ |
Universal ID یا Clean room «جایگزین پیشفرض Cookie» نیستند. Pilot باید Match rate را با Denominator روشن، Reach افزایشی، Quality، Cost، Latency، Privacy control و Exit بسنجد. بالا بودن Match rate بهتنهایی Outcome تجاری یا رضایت معتبر را ثابت نمیکند.
Measurement: Attribution را از Incrementality جدا کنید
Attribution میپرسد Credit ثبتشده را میان Touchpointهای مشاهدهشده چگونه تقسیم کنیم؛ Incrementality میپرسد اگر هزینه/مداخله نبود چه اتفاقی میافتاد. با کاهش Signal، Attribution ناقصتر میشود، اما حتی با Tracking کامل نیز Counterfactual را اثبات نمیکند.
| لایه | پرسش | روش | محدودیت |
|---|---|---|---|
| Delivery | آگهی کجا و چقدر پخش شد؟ | Platform/publisher logs | Viewability/fraud/definition Vendor |
| Observed response | پس از Exposure/Click چه ثبت شد؟ | UTM، click ID، event/order match | Missing identity و selection bias |
| Attribution | Credit مشاهدهشده چگونه توزیع شود؟ | Rule/model با window مشخص | Model-dependent، نه causal |
| Incrementality | چقدر Outcome بهعلت کمپین اضافه شد؟ | Random holdout، geo/time test | Power، spillover، seasonality |
| Portfolio | کانالها در بلندمدت چه سهمی دارند؟ | MMM/causal model | Granularity و assumption |
| Economics | آیا نتیجه سالم و سودآور بود؟ | CRM/Order/Finance reconciliation | Return، margin و lag |
مدلسازی باید Output مشاهدهشده و Estimated را جدا، Method/version، Confidence/interval و Eligibility را ثبت کند. Modeled conversion را بهعنوان Fact row-level وارد CRM نکنید. معماری Event→Warehouse→CRM→Finance و تفاوت Attribution/Incrementality در راهنمای تحلیل دادههای بازاریابی توضیح داده شده است.
Measurement contract: هر Conversion یکسان نیست
| فیلد | مثال | Failure mode |
|---|---|---|
| Outcome | Order paid و پس از window برگشت نگرفته | Click/thank-you page بهجای حقیقت سفارش |
| Eligibility | مشتری جدید، Market مجاز، fraud-free | مخلوط مشتری/کانال نامرتبط |
| Value | Contribution margin، نه Revenue خام | ROAS بالا با Margin/Return بد |
| Timestamp | UTC+Timezone و order/payment dates | Day boundary و duplicate |
| Identity/key | Order ID، lead ID؛ Contact جدا | PII در URL/Event یا join ناامن |
| Consent/use | Analytics/Ads/CRM Scope | استفاده ثانویه بدون مبنای مناسب |
| Deduplication | یک Outcome در web/server/offline | Conversion دو/سهباره |
| Late/Correction | Refund، cancel و lead disqualified | گزارش اولیه هرگز اصلاح نمیشود |
UTM taxonomy باید Source/Medium/Campaign/Content/Term را کنترل و Redirect/short-link را تست کند. Idempotency و Dedup بین Browser tag، server event و Offline import ضروریاند. Data quality dashboard برای Missing، duplication، latency، schema drift، consent mismatch و reconciliation بسازید.
Server-side tagging چه چیزی را حل نمیکند؟
Server-side میتواند Performance، Validation، Redaction، Routing، Credential protection و Control را بهتر کند؛ اما اگر داده را برای همان Purpose و Recipient بفرستید، فقط مسیر عوض شده است. آن را «بدون Cookie»، «Anonymous» یا «مطابق قانون» معرفی نکنید مگر Scope و Evidence دقیق داشته باشید.
| ادعا | واقعیت | Control لازم |
|---|---|---|
| همهچیز First-party شد | Endpoint شما میتواند داده را به Third party forward کند | Destination allowlist و network/data-flow audit |
| Ad blocker حل شد | Circumvention هدف سالم یا پایدار نیست | Respect choice؛ measurement alternative |
| PII امن است | Server هم میتواند PII leak/log کند | Schema validation، redaction، access و retention |
| Conversion دقیق است | Duplicate، fraud و order-state mismatch باقی است | Idempotency و backend truth |
| Consent لازم نیست | Choice/Purpose به Architecture محدود نیست | Consent enforcement در collection/routing |
Vendor scorecard: ابزار را با Exit انتخاب کنید
| محور | پرسش Evidence-based | Red flag |
|---|---|---|
| Data | چه Fieldهایی، برای چه Purpose و کجا پردازش میشوند؟ | «Privacy-safe» بدون Data flow |
| Consent | Grant/deny/withdraw چگونه enforce و log میشود؟ | فقط Banner screenshot |
| Identity | Hash/key/match/linkability و suppression چیست؟ | Hash را Anonymous مینامد |
| Measurement | Observed/Modeled، window و dedup قابل تفکیکاند؟ | عدد واحد بدون method/version |
| Quality | Fraud، viewability، match denominator و SLA؟ | Benchmark بیمنبع |
| Security | Access، encryption، incident و subprocessor؟ | گواهی کلی بدون Scope |
| Portability | Event/raw/aggregate/config/consent export؟ | Dashboard-only و delete نامعلوم |
| Change | API/Policy deprecation و notice؟ | وابستگی به API آزمایشی |
| Iran fit | Eligibility، contract/payment/access/support؟ | دورزدن محدودیت بهعنوان راهحل |
پیش از Contract، Pilot کوچک با Data synthetic/کمینه و Exit drill اجرا کنید: Tag/Vendor را خاموش، Data را export، deletion را درخواست و گزارشهای اصلی را مستقل بازسازی کنید. تصمیم قانونی و Eligibility پلتفرم را با مستند جاری و مشاور متخصص بررسی کنید.
ملاحظات ایران: Access، Attribution و قانون را فرض نکنید
| ریسک ایران | Failure | آزمون/Control |
|---|---|---|
| Platform eligibility/تحریم | Account، Billing یا Support محدود | مستند جاری؛ مسیر قانونی؛ Exit و کانال جایگزین |
| VPN/Geo/IP | Location و Cohort اشتباه | Geo را حقیقت فرد ندانید؛ market confirmation |
| شبکه/Script خارجی | Tag/CMP/Analytics دیر یا Block | چند ISP، timeout و no-script QA |
| ریال/تومان و FX | Value/ROAS دهبرابر یا دوره ناهماهنگ | Currency code، source/date و finance reconciliation |
| Instagram/Telegram/Direct | Referrer/UTM گم و Direct inflated | Controlled link، coupon/question + experiment |
| Offline/تلفنی | Lead به Sale متصل نیست | Lead/order key، status taxonomy و lag window |
| Domestic vendor | Data ownership/export/delete مبهم | Contract، data flow، subprocessor و exit drill |
| قانون چند حوزه | فرض «فقط قانون ایران» یا کپی GDPR | Market/user/processing applicability matrix و counsel |
این بخش مشاوره حقوقی نیست. قانون قابلاعمال به محل کسبوکار، افراد هدف، نوع داده، قراردادها و محل پردازش وابسته است و تغییر میکند. Copy کردن Banner اروپایی بدون Enforcement فنی یا فرض اینکه نبود قانون مشخص مساوی آزادی کامل است، هر دو پرریسکاند. برای کمپین Google Ads، محدودیت جغرافیایی و سنجش سود را در راهنمای تبلیغات گوگل بررسی کنید.
سه سناریوی تصمیم برای کسبوکار ایرانی
فروشگاه کوچک با Traffic کم
Clean room، CDP سنگین یا MMM پیچیده احتمالاً Fit نیست. Priority: Order/Payment truth، UTM منظم، Contextual/Search pilot، Content، Preference/Consent ساده، Email/SMS permissioned، CRM status و Holdout سبک در زمان/شهر مشابه. معیار: Contribution هر سفارش نگهداشتهشده، Repeat و شکایت.
فروشگاه بزرگ یا Marketplace
Catalog/price/stock/order truth، identity/consent ledger، incrementality program، audience suppression، publisher/retail-media partnership و Warehouse مهمتر میشوند. Clean room فقط برای سؤال مشخص، Scale کافی، Governance و خروجی aggregate امتحان شود؛ نه بهعنوان پروژه prestige.
B2B با فروش طولانی و Offline
Lead quality و Account progression از Cookie مهمترند. Source/UTM، form/call event، CRM stage، disqualification reason، sales activity و closed-won/margin را وصل کنید. Window تبلیغ را با Sales cycle هماهنگ و Attribution platform را با Cohort/holdout و Pipeline economics کنترل کنید. Landing و Form باید Promise→Evidence→Action→Outcome را حفظ کنند؛ راهنمای لندینگ پیج و A/B test برای این مسیر است.
برنامه ۹۰روزه مهاجرت از وابستگی به Cookie
روز ۱ تا ۱۵: Inventory و Freeze
- Use case/Tag/Cookie/Storage/Vendor/Data flow و Browser matrix را استخراج کنید.
- Tag جدید بدون Owner، Purpose، Schema، Consent و expiration نپذیرید.
- Order/CRM/Finance outcome و Baseline missing/duplicate/latency را تعریف کنید.
روز ۱۶ تا ۳۰: Consent و Measurement foundation
- Purpose ledger، Data classification، retention/delete و RACI بسازید.
- Grant/deny/withdraw را در UI، network و destination End-to-end تست کنید.
- UTM/Event/Order ID، dedup و correction/refund را پیاده یا اصلاح کنید.
روز ۳۱ تا ۵۰: Failure test و Removal
- 3PC، JavaScript ثالث، Storage، referrer و click ID را جداگانه Block کنید.
- Critical authentication/cart/checkout/embed و dashboard را تست کنید.
- Tagهای بدون Use case یا Evidence را غیرفعال و Regression monitor بسازید.
روز ۵۱ تا ۷۰: Channel pilots
- یک Contextual/Publisher pilot با Placement، Message match و quality outcome اجرا کنید.
- یک Content→Preference→Lifecycle journey با Value exchange روشن بسازید.
- اگر Fit دارد، Customer match/Server-side/Clean room را با Scope و Exit محدود آزمایش کنید.
روز ۷۱ تا ۹۰: Incrementality و Portfolio
- Random/Geo/time holdout مناسب و Guardrail را طراحی کنید.
- Platform report را با CRM/Order/Finance و consent cohort مقایسه کنید.
- بودجه را با Incremental contribution، uncertainty و dependency risk بازتخصیص دهید.
Dashboard تصمیم، نه ویترین Metric
| گروه | Metric نمونه | تفکیک | Guardrail |
|---|---|---|---|
| Reach/Delivery | Viewable/qualified reach و frequency | Publisher/context/browser | Fraud و overlap |
| Relationship | Valid opt-in، preference completion و churn | source/channel/cohort | Complaint/unsubscribe |
| Outcome | Qualified lead، kept order و margin | new/returning، product، region | Return/cancel/fraud |
| Measurement | Observed coverage، modeled share و lift | consent/browser/method | CI/uncertainty و mismatch |
| Data quality | missing، duplicate، latency، schema drift | source/version | reconciliation delta |
| Privacy/Trust | withdraw SLA، deletion، incident و complaint | vendor/purpose | Dark pattern audit |
| Economics | Incremental CAC و contribution | channel/experiment window | FX، internal labor و TCO |
اگر فقط Platform ROAS را نشان دهید، نبود Signal و Self-attribution پنهان میمانند. Report باید Observation، Attribution و Incrementality را برچسب بزند، Denominator و Window را نشان دهد و تغییر Tracking/Consent/Campaign را Annotation کند. طراحی Experiment و Guardrail را با راهنمای UX دادهآگاه همراستا کنید.
چکلیست تبلیغات مقاوم به کاهش Signal
- Snapshot رسمی Chrome/Privacy Sandbox و رفتار Safari/Firefox تاریخدار است.
- Cookieless از Cookie-free، First-party data، Hash و Anonymous تفکیک شده است.
- Use caseهای Session، Audience، Frequency، Attribution، Personalization و Identity Inventory شدهاند.
- Tag/SDK/Storage/CNAME/URL parameter/Vendor و Data flow کاملاند.
- Purpose، Choice/Consent، Retention، Delete، Recipient و Owner ثبت شدهاند.
- Critical flow با 3PC blocked، privacy mode، no-script و چند Browser/ISP تست شده است.
- Contextual campaign Placement/semantic/brand-safety و outcome contract دارد.
- Content و Lead capture Value exchange و Next action روشن دارند.
- Preference center برای Topic/Channel/Frequency و Withdrawal کار میکند.
- Hash، Server-side، Universal ID و Clean room بهعنوان Anonymous معرفی نشدهاند.
- Customer match و Platform activation با Eligibility/Consent/Policy جاری بررسی میشوند.
- Event→Order/CRM→Finance dedup، correction و reconciliation دارد.
- Observed، Modeled، Attribution و Incrementality جدا گزارش میشوند.
- Pilot دارای Baseline، Holdout، Guardrail، Stop rule و Exit است.
- Dashboard کیفیت، Privacy incident، شکایت، Margin و TCO را کنار ROAS نشان میدهد.
پرسشهای متداول
آیا Chrome کوکیهای شخص ثالث را حذف کرده است؟
خیر، حذف سراسری که قبلاً برای ۲۰۲۴ برنامهریزی شده بود اجرا نشد. Google در آوریل ۲۰۲۵ حفظ رویکرد جاری انتخاب Cookie در Chrome را اعلام کرد و در اکتبر ۲۰۲۵ چند API اصلی Privacy Sandbox از جمله Topics و Protected Audience را برای بازنشستگی فهرست کرد. تنظیم کاربر، Mode و Browser همچنان رفتار را تغییر میدهد.
آیا تبلیغات بدون کوکی یعنی هیچ Cookieای استفاده نمیشود؟
خیر. First-party cookie برای Login، Session، Cart یا Preference ممکن است لازم و سالم باشد. موضوع اصلی کاهش اتکا به Third-party cookie و Cross-site identifiers است. هر Cookie و Storage باید Purpose، Security، Retention و Choice متناسب داشته باشد.
آیا داده شخص اول خودکار مجاز و بیخطر است؟
خیر. First-party بودن فقط رابطه جمعآوری را توصیف میکند. استفاده باید با Purpose، اطلاعرسانی، Consent یا مبنای قابلاعمال، Retention، Security، Sharing و حقوق افراد سازگار باشد. داده کمتر و تازهتر معمولاً از انبار بزرگ بیهدف ارزشمندتر است.
آیا Hash ایمیل یا Server-side tagging داده را ناشناس میکند؟
معمولاً نه. ایمیل Hashشده میتواند برای Match طراحی شده باشد و همچنان Linkability دارد؛ Server-side فقط مسیر پردازش را عوض میکند. Data classification، access، key/salt، destination، consent، retention و deletion را بررسی کنید و ادعای Anonymous را با Threat model اثبات کنید.
کسبوکار کوچک از کجا شروع کند؟
از Clean room یا CDP شروع نکنید. ابتدا Tag/Cookie inventory، Order/CRM truth، UTM و Event ساده، Consent/Preference قابلفهم، یک Contextual یا Search pilot، محتوای مفید و Email/SMS permissioned بسازید. سپس با Holdout سبک و Margin واقعی تصمیم بودجه بگیرید.
جمعبندی
آینده تبلیغات «بدون داده» نیست؛ با Signal کمتر، Choice بیشتر و Measurement نامطمئنتر است. برنده تیمی نیست که Third-party cookie را با Fingerprinting، CNAME یا شناسه مبهم جایگزین کند؛ تیمی است که Demand را در Context درست بسازد، رابطه مستقیم را با Permission نگه دارد و اثر افزایشی را با Outcome مستقل بسنجد.
از Inventory شروع کنید: هر Use case، Signal، Vendor، Purpose و تصمیمی را که تغذیه میکند ثبت کنید. سپس وابستگی را در Browserهای مختلف بشکنید، داده و Consent را به Contract تبدیل کنید و دو Pilot محدود—یکی برای Demand و یکی برای Measurement—اجرا کنید. Trust را نیز مانند Revenue اندازه بگیرید؛ معماری بازاریابی وقتی پایدار است که کاربر بتواند انتخاب کند و کسبوکار حتی با Missing signal تصمیم معقول بگیرد.
