سرور MCP داده‌لند در دسترس قرار گرفت؛ مدیریت و تحلیل داده‌های سازمان با ابزارهای هوش مصنوعی فراهم شد.

عملیات

یکپارچه‌سازی‌های توزیع داده

در این صفحه با نحوه اتصال و پیکربندی مقاصد آماده نظیر تلگرام و تبدیل‌های آفلاین گوگل ادز در توزیع داده آشنا می‌شوید.

مقاصد آماده (Pre-built Destinations) در توزیع داده، اتصالات بهینه‌سازی‌شده‌ای هستند که کاربران را از درگیری با جزئیات فنی پروتکل HTTP (تنظیم دستی متدها، هدرها، پی‌لودها و احراز هویت) بی‌نیاز می‌سازند. با انتخاب هر مقصد آماده، فرم تعریف مقصد در تنظیمات فضا و پایپ‌لاین پیکربندی فرآیند متناسب با ضوابط همان پلتفرم هماهنگ می‌گردند.

مقاصد آماده

داده‌لند در حال حاضر از دو مقصد آماده استاندارد برای ارتباطات و بازاریابی پشتیبانی می‌کند:

نام مقصد	نوع کاربرد	پروتکل ارتباطی
تلگرام (Telegram)	ارسال پیام‌ها، هشدارهای نظارتی و گزارش‌های شاخص‌های کلیدی به کانال، گروه یا تاپیک.	ارسال مستقیم با بات تلگرام (Bot API).
گوگل ادز (Google Ads)	همگام‌سازی تبدیل‌های آفلاین (Offline Conversions) و انتساب خارجی چندکاناله.	واکشی زمان‌بندی‌شده فایل امن توسط سرورهای گوگل (Scheduled Uploads).

تعریف اولیه این مقاصد در سطح فضا از مسیر مدیریت فضا > مقصدهای مجاز توسط مالک یا مدیر فضا انجام می‌پذیرد.

مقصد تلگرام

این مقصد جهت ارسال خودکار اعلان‌ها، شاخص‌های عملکرد و هشدارهای رکوردی به چت‌های تلگرام به کار می‌رود:

در صفحه مقصدهای مجاز با انتخاب گزینه مقصد آماده تلگرام، مشخصات زیر تکمیل می‌گردند:

عنوان تنظیم	نوع مقدار	توضیحات و رفتار سیستم
نام مقصد	متنی	نام نمایشی یکتا برای شناسایی مقصد در سطح فضا است.
توکن ربات	متنی (Secret)	توکن محرمانه ربات دریافت‌شده از BotFather است و در تمامی لاگ‌های سیستم به صورت ماسک‌شده نگهداری می‌شود.
نوع مقصد	انتخابی	بستر دریافت پیام در تلگرام شامل کانال، گروه معمولی یا تاپیک در سوپرگروه است.

مشخصات شناسه برای هر یک از بسترهای تلگرام به شرح زیر وارد می‌شوند:

کانال: برای کانال‌های عمومی از آیدی عمومی با علامت @ و برای کانال‌های خصوصی از شناسه عددی منفی با پیشوند -100 استفاده می‌شود.
گروه معمولی: شناسه عددی منفی گروه وارد می‌گردد.
تاپیک در سوپرگروه: شناسه سوپرگروه با پیشوند -100 و شناسه عددی تاپیک تعیین می‌گردند. قابلیت Topics باید در سوپرگروه فعال باشد.

تنظیمات رابط کاربری هنگام ساخت فرآیند متصل به تلگرام در جدول زیر خلاصه شده‌اند:

عنوان تنظیم	گام فرآیند	نوع مقدار / گزینه‌ها	توضیحات و رفتار سیستم
نوع متن	گام ۳ (داده)	متن ساده / قالب‌بندی HTML	در حالت ساده متن خام فرستاده می‌شود و در حالت HTML استفاده از تگ‌های استاندارد تلگرام مجاز است.
تیک ارسال به مقصد	گام ۴ (ارسال)	منحصراً ستون `text`	تنها تیک ستون `text` روشن و قفل است و سایر ستون‌ها به تلگرام ارسال نمی‌شوند.
سوییچ کلید یکتاسازی	گام ۴ (ارسال)	آزاد برای تمامی ستون‌ها	کاربر می‌تواند شناسه‌های دلخواه را به عنوان کلید یکتاسازی جهت جلوگیری از پیام‌های تکراری فعال کند.

ضوابط فنی کوئری و نرخ ارسال برای مقصد تلگرام به شرح زیر اعمال می‌گردند:

الزامات کوئری:
- خروجی دستور SELECT الزاماً باید شامل ستونی با عنوان دقیق text باشد.
- حداکثر طول مجاز ستون text برابر با ۴۰۹۶ کاراکتر است. رکوردهای طولانی‌تر جهت جلوگیری از ارسال ناقص فرستاده نمی‌شوند و خطای آن‌ها در لاگ ثبت می‌گردد.
- استخراج ستون‌های کمکی دلخواه (نظیر شناسه کاربر یا سفارش) در کوئری مجاز است و سیستم این ستون‌ها را خطا تلقی نمی‌کند.
- در حالت اجرای خودکار، فراخوانی ستون record_time برای هدایت نشانگر واترمارک الزامی است.
کنترل نرخ ارسال (Rate Limiting):
- در هر نوبت اجرا حداکثر ۲۰ رکورد نخست ارسال می‌شوند.
- بین هر پیام وقفه ۱ تا ۲ ثانیه‌ای جهت رعایت قوانین ضداسپم تلگرام لحاظ می‌گردد.

مقصد گوگل ادز

این مقصد امکان همگام‌سازی تبدیل‌های آفلاین (Offline Conversions) و اعمال مدل‌های انتساب خارجی را بدون نیاز به توکن‌های پیچیده توسعه‌دهنده گوگل مهیا می‌سازد:

در صفحه مقصدهای مجاز با انتخاب گزینه مقصد آماده گوگل ادز، مشخصات زیر تکمیل و دریافت می‌گردند:

عنوان تنظیم	نوع فیلد	توضیحات و رفتار سیستم
نام مقصد	ورودی کاربر	نام نمایشی یکتا برای شناسایی مقصد در سطح فضا است.
نشانی واکشی	سیستمی (غیرقابل ویرایش)	نشانی امن و اختصاصی HTTPS همراه با دکمه کپی است که باید در بخش Conversions > Uploads > Schedules پنل گوگل ادز ثبت شود.
تست اتصال	پنهان	با توجه به سازوکار واکشی یک‌طرفه توسط سرورهای گوگل (مکانیزم Pull)، دکمه تست اتصال در این فرم وجود ندارد.

فرآیند تبدیل‌های آفلاین گوگل ادز متناسب با ساختار داده‌ها به دو شیوه قابل پیکربندی است:

روش فرم‌ساز خودکار (پیش‌فرض): این روش گزینه‌ای خودکار برای رویدادهای ماژول کلاینت (events) است که محاسبات انتساب و تخصیص سهم‌های کسری را به شکل بهینه انجام می‌دهد. مشخصات این فرم‌ساز در جدول زیر تنظیم می‌گردند:

عنوان تنظیم	نوع مقدار	توضیحات و رفتار سیستم
جدول رویدادها	انتخابی	جدول رویدادهای ماژول کلاینت (مانند `events`) به عنوان منبع خام انتخاب می‌شود.
انتخاب رویدادها	چندانتخابی	یک یا چند رویداد مدنظر جهت سنجش تبدیل (نظیر `purchase` یا `lead`) تعیین می‌گردند.
نام اکشن در گوگل ادز	متنی	نام دقیق و یکتای اکشن تبدیل در پنل گوگل ادز با رعایت حساسیت به حروف کوچک و بزرگ و فاصله وارد می‌شود.
مسیرهای مجاز	متنی (اختیاری)	فیلتر اختیاری مسیرهای URL وقوع رویداد است و خالی گذاشتن آن به معنای پذیرش تمامی مسیرها خواهد بود.
مدل انتساب	انتخابی	انتساب در دو ساختار لحظه‌ای یا پنجره زمانی بازگشت (از ۵ دقیقه تا ۳۰ روز) تعیین می‌گردد. در پنجره بازگشت، محاسبه سهم بر پایه یکی از ۵ مدل آخرین کلیک (اعتبار کامل به کلیک آخر)، اولین کلیک (اعتبار کامل به کلیک اول)، سهم برابر (تقسیم مساوی میان کلیک‌ها)، کاهش زمانی (اعطای وزن بیشتر به کلیک‌های نزدیک‌تر به خرید) یا مبتنی بر جایگاه (۴۰ درصد به کلیک اول، ۴۰ درصد به کلیک آخر و ۲۰ درصد میان کلیک‌های میانی) انجام می‌پذیرد.
ارسال ارزش و واحد پول	سوییچ (اختیاری)	فعال‌سازی این سوییچ اختیاری است و در صورت خاموش بودن، ستون‌های ارزش و ارز با مقدار `NULL` ارسال می‌شوند.
کلید JSON مبلغ	متنی	در صورت فعال بودن سوییچ ارزش، مسیر کلید مبلغ ریالی از ستون متادیتای JSON با نام `meta` (مانند `$.amount`) مشخص می‌شود.
جدول نرخ ارز	انتخابی	جدول حاوی نرخ‌های تاریخی ارز جهت تبدیل مبالغ ریالی به ارز حساب گوگل ادز انتخاب می‌گردد و امکان تأمین خودکار آن از طریق ماژول نرخ ارز مهیا است.
انتخاب ارز مقصد	انتخابی	واحد پول حساب از میان فهرست ۱۰ ارز فعال گوگل ادز (با پیش‌فرض لیر ترکیه `TRY`، در کنار `AED`، `INR`، `USD`، `EUR`، `GBP`، `CAD`، `AUD`، `CNY` و `SAR`) انتخاب می‌شود.

روش کوئری دستی SQL: این شیوه برای سناریوهایی به کار می‌رود که نیازمند پیوند (JOIN) میان رویدادهای کلاینت با سایر جداول پایگاه داده (مانند سفارشات CRM، پایگاه فاکتورها یا جداول مالی) باشند. نگارش کوئری در این حالت کاملاً آزاد است، اما خروجی نهایی دستور SELECT الزاماً باید ستون‌های استاندارد و ضوابط فنی گوگل ادز را تأمین نماید.

خروجی نهایی کوئری گوگل ادز (در حالت دستی یا فرم‌ساز) باید ستون‌های استاندارد زیر را با عنوان دقیق تولید نماید:

نام ستون	وضعیت	فرمت و توضیحات
`Google Click ID`	الزامی	شناسه معتبر کلیک تبلیغاتی گوگل با کد `gclid` است.
`Conversion Name`	الزامی	نام دقیق اکشن تبدیل در پنل گوگل ادز است.
`Conversion Time`	الزامی	زمان دقیق تبدیل با ساختار متنی `yyyy-mm-dd hh:mm:ss+0330` است.
`Attributed credit`	الزامی	سهم کسری انتساب با فرمت اعشاری و اکیداً بزرگتر از صفر تا حداکثر ۱.۰ است.
`Conversion Value`	اختیاری (جفت‌شده)	مبلغ سهم تبدیل با ۲ رقم اعشار است (در صورت عدم ارسال ارزش، مقدار `NULL` می‌گیرد).
`Conversion Currency`	اختیاری (جفت‌شده)	یکی از ۱۰ ارز مجاز گوگل ادز است (در صورت عدم ارسال ارزش، مقدار `NULL` می‌گیرد).

قانون جفت بودن ستون‌های ارزش: دو ستون Conversion Value و Conversion Currency کاملاً جفت و وابسته به یکدیگر هستند. در صورت ارسال ارزش تبدیل، تکمیل هر دو فیلد الزامی است و مقدار واحد پول الزاماً باید یکی از ۱۰ ارز مجاز مذکور در بخش قبل باشد و مقداری خارج از آن پذیرفته نمی‌شود. در غیر این صورت هر دو فیلد باید مقدار NULL داشته باشند.

توصیه وقفه ۶ ساعته (Click too recent): پردازش و ثبت اولیه کلیک‌ها در سرورهای گوگل ادز معمولاً تا ۶ ساعت زمان نیاز دارد و ارسال تبدیل‌های تازه‌تر از ۶ ساعت ممکن است با خطای Click too recent از سمت گوگل رد شود. بنابراین پیشنهاد می‌گردد برای جلوگیری از بروز این خطا، شرط زمانی مشابه نمونه زیر در نظر گرفته شود:

`conversion_time` <= DATE_SUB(NOW(), INTERVAL 6 HOUR)

توصیه زمان‌بندی فرآیند: با توجه به وقفه زمانی سرورهای گوگل ادز در پردازش کلیک‌ها (Click too recent)، اجرای فرآیند در فواصل کوتاه‌تر از ۶ ساعت هیچ اثری در تسریع ثبت تبدیل‌ها ندارد. بنابراین تعیین فواصل ۶ ساعت به بالا (نظیر ۶ ساعت، ۱۲ ساعت یا روزانه) صرفاً توصیه می‌شود و اجباری در سامانه نیست. همچنین به دلیل ایجاد تاخیر بیش از حد در پنجره تبدیل و اختلال در الگوریتم‌های هوشمند پیشنهاد قیمت (Smart Bidding) گوگل ادز، استفاده از فرکانس هفتگی پیشنهاد نمی‌گردد.
قفل یکتاسازی سه‌گانه (گام ۴): سوییچ یکتاسازی برای ۳ ستون الزامی شامل Google Click ID، Conversion Name و Conversion Time به صورت خودکار روشن و قفل است تا از ثبت تبدیل‌های تکراری جلوگیری شود. تعیین بازه زمانی جست‌وجو در لاگ بر عهده کاربر است و جهت پوشش کامل تاخیرها معمولاً بازه‌های ۴۸ یا ۷۲ ساعت گذشته پیشنهاد می‌شوند.