اتریبیوشن بدون کوکی: برنامه داده شخص اول برای کلینیک
برنامه داده شخص اولی که کلینیک در شش ماه میسازد: رضایت و consent mode، هویت CRM، جمعآوری سمت سرور و بازنویسی تبدیل آفلاین.
نوشته Roozbeh Nazari · CEO
پایان کوکی شخص ثالث چند بار عقب افتاد و گوگل سرانجام اعلام کرد از برنامه حذف اجباری آن در Chrome منصرف شده؛ اما مشکل اتریبیوشن کلینیکها از اول هم محدود به کوکی نبود. به خاطر محدودیتهایی که Safari و Firefox سالهاست اعمال میکنند، پیام مجوز ردیابی iOS، مدیریت رضایت و مسدودکنندههای تبلیغ، بخشی از تبدیلهای سایت کلینیک اصلاً به لایه اندازهگیری نمیرسد. این مقاله درباره نظریه بحث «cookieless» نیست، بلکه برنامه داده شخص اولی را شرح میدهد که یک کلینیک میتواند در شش ماه بسازد: چه چیزی جمع میکنید، با کدام مجوز، به کجا میفرستید و در کدام گزارش میخوانید.
سمت مفهومی موضوع را پیشتر در مقاله اتریبیوشن بدون کوکی بررسی کرده بودیم؛ اینجا همان مسئله را روی مثال یک کلینیک و به ترتیب راهاندازی دنبال میکنیم. کلینیک مثال، سایتی به چهار زبان، جریان لید عمدتاً مبتنی بر WhatsApp و یک CRM دارد؛ در سمت تبلیغات هم Google Ads و Meta.
لایه اول: رضایت و زمین حقوقی
برنامه داده شخص اول با حقوق شروع میشود، نه با فن. هر دادهای که در سایت کلینیک جمع میشود با داده سلامت تماس دارد؛ وقتی بیمار از صفحه یک درمان فرم پر میکند، خود فرم اظهار علاقهای درباره سلامت است. در قانون حفاظت از داده ترکیه (KVKK) داده سلامت، داده شخصی با ماهیت ویژه است؛ بنابراین هر یک از گامهای جمعآوری، نگهداری و انتقال به پلتفرم تبلیغاتی ارزیابی حقوقی جداگانه میخواهد. این مقاله نظر حقوقی نیست؛ پیش از اجرای برنامه، متن اطلاعرسانی، سازوکار رضایت صریح و شرایط انتقال را با مشاور حفاظت از داده خود روشن کنید.
معادل فنیاش پلتفرم مدیریت رضایت و consent mode گوگل است. مستندات گوگل میگوید consent mode بنر خودش را ندارد و تصمیم بنر رضایت موجود را به تگها منتقل میکند؛ در حالت پایه تا رضایت نیاید هیچ تگی بارگذاری نمیشود، در حالت پیشرفته تگها بارگذاری میشوند، اگر رضایت نباشد پینگ بدون کوکی میفرستند و گوگل این خلأ را با مدلسازی پر میکند. اینکه کدام حالت برای کلینیک مناسب است نتیجه ارزیابی حقوقی است؛ ما فقط یادآوری میکنیم که نتیجه اندازهگیری این دو حالت متفاوت است.
لایه دوم: هویت و CRM
ستون فقرات اتریبیوشن بدون کوکی، کوکی نیست؛ هویتی است که شما میدهید. بیمار در اولین تماس یک رکورد CRM میگیرد؛ اطلاعات منبع (کمپین، صفحه، زبان، شناسه کلیک) در لحظه اولین تماس در آن رکورد نوشته میشود و هر گام بعدی (مشاوره، پیشنهاد قیمت، بیعانه، درمان) به همان رکورد اضافه میشود. جزئیات این راهاندازی برای جریان مبتنی بر WhatsApp را در مقاله قیف WhatsApp Business API شرح دادهایم.
در سمت GA4 این هویت با User-ID حمل میشود. صفحه راهنمای گوگل میگوید User-ID شناسه خود شما را به رفتار کاربر گره میزند، نباید از 256 نویسه بیشتر باشد و نباید اطلاعاتی داشته باشد که شخص ثالث بتواند با آن فرد را شناسایی کند. در عمل شماره بیمار خود CRM استفاده نمیشود، بلکه یک توکن تصادفی مشتق از آن؛ انتخاب «ترکیبی» یا «مشاهدهشده» در هویت گزارشگیری را هم در همین مرحله انجام میدهید.
لایه سوم: جمعآوری سمت سرور
بخشی از تگهایی که در مرورگر اجرا میشوند اصلاً اجرا نمیشوند. تگگذاری سمت سرور رویداد را اول به سروری زیر کنترل شما میفرستد و از آنجا به پلتفرمها میرساند؛ تصمیم اینکه کدام داده به کدام پلتفرم برود روی سرور شما گرفته میشود. تصمیمهای راهاندازی و اقلام هزینه را در مقاله تگگذاری سمت سرور به تفصیل بررسی کردهایم. معادلش در سمت Meta، Conversions API است؛ مستندات Meta توضیح میدهد رویدادهایی که از سرور فرستاده میشوند مثل رویدادهای Pixel پردازش میشوند و وقتی یک رویداد از دو کانال برسد، حذف تکرار انجام میشود.
لایه چهارم: بازنویسی تبدیل
در کلینیک تبدیل واقعی در سایت رخ نمیدهد؛ درمان هفتهها بعد، در کلینیک انجام میشود. مستندات واردکردن تبدیل آفلاین Google Ads دقیقاً همین وضعیت را توصیف میکند: به هر کلیک تبلیغ یک شناسه (GCLID) اختصاص مییابد، شما آن را در CRM نگه میدارید و وقتی تبدیل رخ داد همراه با شناسه پس میفرستید. همان سند میگوید این بارگذاریها از 15 ژوئن 2026 به Data Manager API منتقل شدهاند؛ یکپارچهسازیهایی که هنوز از مسیر قدیمی Google Ads API استفاده میکنند باید بهروز شوند.
تبدیلهای پیشرفته مسیر دوم بازنویسی است. مستندات گوگل توضیح میدهد داده شخص اول مثل ایمیل و تلفن نرمالسازی و با SHA256 هش میشود و بعد فرستاده میشود، و گونه «تبدیلهای پیشرفته برای لید» لید وب را با فروش آفلاین تطبیق میدهد. اینجا یک نکته ویژه برای کلینیک لازم است: انتقال داده شخصی هششده به پلتفرم تبلیغاتی در بستر داده سلامت، در دامنه ارزیابی حقوقی لایه اول قرار میگیرد و سیاستهای پلتفرمها درباره شخصیسازی مرتبط با سلامت محدودیت بیشتری میآورد. ممکن بودن فنی به معنای لزوم انجام نیست.
چه چیزی را جمع نکنید
برنامه داده شخص اول، برنامه «همه چیز را جمع کن» نیست. امنترین اصل برای کلینیک، کمینهسازی داده است: آنچه اتریبیوشن لازم دارد این است که بیمار از کدام منبع آمده و به کدام مرحله رسیده؛ نه اینکه درباره کدام درمان پرسیده، سابقه سلامتش چیست یا چه عکسی بارگذاری کرده. این گروه دوم در CRM میماند و هرگز وارد لایه اندازهگیری نمیشود. در پارامترهای رویدادی که به GA4 فرستاده میشود، به جای نام درمان دسته صفحه و به جای محتوای پیام WhatsApp فقط این اطلاع که گفتگویی شروع شده حمل شود. برای هر فیلدی که به پلتفرم میرود بپرسید «بدون این نمیتوانیم اتریبیوشن کنیم؟»؛ جواب بیشتر وقتها «میتوانیم» است.
ترتیب اجرای ششماهه
- ماه 1: فهرست داده، متن اطلاعرسانی، پلتفرم رضایت و تصمیم consent mode.
- ماه 2: فیلدهای منبع و نگهداری شناسه کلیک در CRM؛ نوشتن منبع در جریان WhatsApp و فرم.
- ماه 3: کانتینر سمت سرور، User-ID در GA4، Meta Conversions API و تست حذف تکرار.
- ماه 4: بازنویسی تبدیل آفلاین (Data Manager API) و تصمیم تبدیلهای پیشرفته.
- ماه 5-6: کنار هم گذاشتن گزارش پلتفرم و گزارش CRM، تحلیل انحراف و خواندن اثر مدلسازی.
در گزارش چه میخوانید
خروجی این برنامه یک جدول است: تعداد لید، مشاوره، بیعانه و درمان به تفکیک منبع، از CRM. گزارشهای پلتفرم کنار این جدول گذاشته میشوند، نه بالای آن؛ تعداد تبدیلی که Google Ads نشان میدهد مدلسازیشده است، عدد CRM مشاهدهشده است و فاصله این دو میگوید کدام لایه برنامه ناقص است. اگر فاصله بزرگ و به نفع پلتفرم باشد، یعنی مدلسازی زیادی خوشبین است یا حذف تکرار کار نمیکند؛ اگر به نفع CRM باشد، یعنی شناسههای کلیک ثبت نمیشوند یا بازنویسی ناقص است. این خوانش ماهی یک بار انجام میشود و هر ماه با اصلاح یک لایه تمام میشود. راهاندازی این گزارش تحویل استاندارد خدمت تحلیل داده ماست؛ تفاوتش برای کلینیکها این است که محدودیتهای داده سلامت در هر لایه تعبیه شده است.
نتیجه
اتریبیوشن در دنیای بدون کوکی، پیدا کردن کوکی جدیدی به جای کوکی گمشده نیست؛ نگه داشتن هویت، رضایت و تبدیل در سیستم خودتان و پس دادن کنترلشده آنها به پلتفرمهاست. برای کلینیک ترتیب عوض نمیشود: اول حقوق، بعد هویت، بعد جمعآوری سمت سرور و در آخر بازنویسی. پروژههایی که این ترتیب را وارونه میکنند با راهاندازیای تمام میشوند که از نظر فنی کار میکند اما از نظر حقوقی قابل دفاع نیست.