OpenAI
این صفحه به‌صورت ماشینی ترجمه شده است. مقاله اصلی انگلیسی را مشاهده کنید.

عیب‌یابی ردیابی تبدیل برای تبلیغات ChatGPT

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

به‌روزرسانی: 2 hours ago

نمای کلی

اگر رویدادها نمایش داده نمی‌شوند، درخواست‌ها ناموفق‌اند یا داده‌های سامانهٔ مدیریت تبلیغات با سوابق کسب‌وکارتان هم‌خوانی ندارند، از این راهنما استفاده کنید. با یک خرید تکمیل‌شده، یک سرنخ ثبت‌شده یا اقدامی دیگر شروع کنید. یادداشت کنید چه اتفاقی و در چه زمانی افتاده است، سپس پرسش مرتبط را از میان پرسش‌های زیر انتخاب کنید.

رویداد، اقدامی مانند خرید را ثبت می‌کند. پیکسل رویدادها را از مرورگر بازدیدکننده ارسال می‌کند؛ API تبدیل‌ها (CAPI) آن‌ها را از سرور شما می‌فرستد. سامانهٔ مدیریت تبلیغات این رویدادها را در یک منبع داده جمع‌آوری می‌کند. انتساب مشخص می‌کند که اقدام به کدام تبلیغ نسبت داده شود. بازهٔ انتساب مشخص می‌کند تا چه مدت پس از تعامل با تبلیغ، یک اقدام می‌تواند واجد شرایط انتساب باشد.

پرسش‌های متداول

۱. از کجا شروع کنم؟

مشخص کنید کدام اقدام را می‌خواهید اندازه‌گیری کنید، چه چیزی رویداد آن را ارسال می‌کند و از کدام حساب تبلیغاتی و شناسهٔ پیکسل استفاده می‌شود. در راه‌اندازی شما ممکن است از پیکسل، CAPI، یکپارچه‌سازی با سرویس شریک یا ترکیبی از این‌ها استفاده شده باشد. CAPI حتی اگر پیکسل مرورگر را نصب نکرده باشید، به شناسهٔ پیکسل نیاز دارد.

برای راه‌اندازی اولیه، به اندازه‌گیری تبدیل و ردیابی تبدیل مراجعه کنید. توسعه‌دهندهٔ شما می‌تواند از راهنماهای پیکسل، CAPI و رویدادهای پشتیبانی‌شده استفاده کند. درخواست‌ها و کلیدهای CAPI را روی سرور خود نگه دارید.

اگر یک شریک، یکپارچه‌سازی شما را مدیریت می‌کند، از راهنمای راه‌اندازی شریک اندازه‌گیری یا راهنمای راه‌اندازی شریک اندازه‌گیری موبایل استفاده کنید. برای اتصال به HubSpot، به راه‌اندازی تبلیغات ChatGPT در HubSpot مراجعه کنید.

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

  • آیا انجام اقدام باعث ارسال درخواست رویداد شد؟

  • آیا درخواست با خطا مواجه شد یا پذیرفته شد؟

  • آیا می‌توانید تأیید کنید که منبع دادهٔ درست، رویداد را دریافت کرده است؟

  • آیا در گزارش کمپین، رویداد به یک تبلیغ نسبت داده شد؟

۲. پیکسل را نصب کرده‌ام. چرا خریدها یا سرنخ‌ها را نمی‌بینم؟

ممکن است پیکسل بارگیری شود، اما رویداد خرید یا سرنخ موردنیاز شما را ارسال نکند. از توسعه‌دهندهٔ خود بخواهید یک اقدام تکمیل‌شده را بررسی کند:

  • نام رویداد، شناسهٔ پیکسل و صفحه یا تابع بازگشتیِ ارسال‌کنندهٔ آن را بررسی کنید. بازدید از صفحه به معنای خرید تکمیل‌شده نیست.

  • مطمئن شوید پیکسل پیش از ارسال رویداد مقداردهی اولیه می‌شود، حتی زمانی که ابزار مدیریت تگ آن را بارگیری می‌کند.

  • کنسول مرورگر و درخواست شبکه را بررسی کنید. پیام «اجرا شد» در ابزار مدیریت تگ، به‌تنهایی تأیید نمی‌کند که رویداد ارسال شده است. حالت اشکال‌زدایی پیکسل می‌تواند کمک‌کننده باشد.

  • بررسی کنید آیا انتخاب‌های کاربر دربارهٔ رضایت، مسدودسازی مرورگر یا سیاست امنیتی سایت شما مانع ارسال درخواست شده‌اند.

  • صفحات نیازمند ورود به حساب، فرایند پرداخت، سایت‌های رزرو، تغییرمسیرها و فرم‌های تعبیه‌شده را بررسی کنید. کارکرد درست پیکسل در صفحهٔ فرود، به معنای تأیید ردیابی در سایر بخش‌ها نیست.

اگر هیچ درخواستی ارسال نشده است، ابتدا همان مرحله را اصلاح کنید. منتظر گزارش ماندن کمکی نمی‌کند. پیش از افزودن یکپارچه‌سازی دیگری، از راهنمای عیب‌یابی پیکسل استفاده کنید.

۳. اگر رویداد رد شود، مهلت درخواستش به پایان برسد یا با خطای سرور مواجه شود، چه کار کنم؟

کد پاسخ، متن دقیق خطا، زمان درخواست و شناسهٔ رویداد را ذخیره کنید. از توسعه‌دهندهٔ خود بخواهید قالب رویداد، شناسهٔ پیکسل و کلید را بررسی کند. درخواست‌های رویداد CAPI از کلید API تبدیل‌های همان حساب تبلیغاتی استفاده می‌کنند. درخواست‌های راه‌اندازی، مدیریت و گزارش‌گیری از کلید جداگانهٔ API تبلیغ‌دهنده استفاده می‌کنند. کلیدهای API را برای پشتیبانی ارسال نکنید.

در ارسال دسته‌ای CAPI، یک رویداد نامعتبر می‌تواند باعث ناموفق‌شدن کل دسته شود.

CAPI به زمان اصلی انجام اقدام در قالب زمان یونیکس برحسب میلی‌ثانیه نیاز دارد. زمان رویداد نباید قدیمی‌تر از ۷ روز گذشته یا بیش از ۱۰ دقیقه جلوتر از زمان فعلی باشد. این محدودیت ارسال، جدا از بازهٔ انتساب است. زمان یک رویداد قدیمی را برای پذیرفته‌شدن آن تغییر ندهید.

پایان مهلت درخواست یا خطای سرور ممکن است باعث شود ندانید رویداد رسیده است یا نه. درخواست اصلی و هرگونه سابقهٔ دریافت را بررسی کنید. اگر ارسال همان اقدام را دوباره امتحان می‌کنید، شناسهٔ رویداد و مهر زمانی اصلی آن را حفظ کنید. شناسهٔ جدید ممکن است باعث شود رویداد، اقدام دیگری تلقی شود.

ردشدن درخواست یا شکست مداوم آن را بی‌درنگ بررسی کنید. زمان تقریبی ۲۴ تا ۴۸ ساعت برای نمایش در گزارش، در مورد این خطاها صدق نمی‌کند. برای الزامات درخواست، به API تبدیل‌ها مراجعه کنید.

۴. می‌بینم که رویداد پذیرفته شده است. چرا در گزارش نیست؟

پذیرفته‌شدن رویداد به این معنا نیست که به یک تبلیغ نسبت داده شده است. بررسی کنید پاسخ چه چیزی را تأیید می‌کند و آیا درخواست از منبع دادهٔ درست استفاده کرده است. در CAPI، تنظیم validate_only روی true رویدادها را بدون ذخیره‌کردن آن‌ها بررسی می‌کند.

برای یک رویداد جدید، توسعه‌دهندهٔ شما می‌تواند در صورت دسترسی، رویدادهای اخیر را بررسی کند. این بخش نمونه‌ای از رویدادهای اخیر را نشان می‌دهد، نه تاریخچهٔ کامل یا نتیجهٔ انتساب را.

اگر نمی‌توانید دریافت را بررسی کنید، با پشتیبانی تماس بگیرید و پاسخ اصلی و یک نمونه رویداد را ارائه دهید. به ما بگویید چه بررسی‌هایی انجام داده‌اید؛ لازم نیست ابتدا علت را پیدا کنید.

اگر دریافت تأیید شده است، به پرسش ۵ بروید. صرفاً به این دلیل که گزارش کمپین تغییر نکرده است، رویداد را با شناسه‌های جدید دوباره ارسال نکنید.

نمایش تبدیل‌های منتسب‌شده ممکن است حدود ۲۴ تا ۴۸ ساعت طول بکشد و آمار کلِ اخیر ممکن است در طول پردازش تغییر کند. این به معنای تضمین نمایش همهٔ رویدادهای پذیرفته‌شده یا تأیید دریافت آن‌ها نیست. به اندازه‌گیری نتایج مراجعه کنید.

۵. رویدادها دریافت می‌شوند. چرا کمپین همچنان صفر تبدیل نشان می‌دهد؟

پیش از تغییر یکپارچه‌سازی، این موارد را بررسی کنید:

  • آیا منبع دادهٔ موردنظر به حساب درست متصل است؟

  • آیا رویدادی که ارسال می‌کنید با تنظیم تبدیلِ کمپین مطابقت دارد؟ برای رویدادهای سفارشی، نوع سفارشی و نام دقیق رویداد را بررسی کنید. یکسان‌بودن برچسب نمایشی کافی نیست.

  • آیا پیش از فعالیتی که بررسی می‌کنید، تبدیل درست به کمپین پیوند داده شده بود؟

  • آیا اقدام پس از کلیک یا مشاهدهٔ تبلیغی رخ داده که طبق تنظیمات انتساب، واجد شرایط است؟

  • آیا کمپین، ستون رویداد، تاریخ‌ها و مبنای زمانی گزارش‌گیری را درست انتخاب کرده‌اید؟

اطلاعات تطبیق به مرتبط‌کردن رویداد با تبلیغ کمک می‌کند، اما انتساب را تضمین نمی‌کند. مرجع واقعی کلیک OpenAI، یعنی oppref، را در طول بازدید حفظ کنید و در صورت موجودبودن، آن را در رویدادهای سرور بگنجانید. هرگز مرجع ساختگی ایجاد نکنید یا از مرجع بازدیدکنندهٔ دیگری استفاده نکنید.

رویدادهای مرورگر و سرور را جداگانه بررسی کنید. ممکن است مرجع یا فیلد اطلاعات مشتری که در دسترس پیکسل است، در رویداد سرور وجود نداشته باشد.

هدف انتخاب‌شدهٔ کمپینی که برای تبدیل بهینه‌سازی شده است، پس از ایجاد قابل‌تغییر نیست. برای استفاده از هدفی دیگر، کمپین جدیدی ایجاد کنید. رویدادهای سفارشی نمی‌توانند هدف بهینه‌سازی باشند. به کمپین‌های بهینه‌شده برای تبدیل مراجعه کنید.

پس از رفع ناهماهنگی در پیکربندی، فعالیت‌های جدیدِ واجد شرایط را بررسی کنید. فرض نکنید این تغییر، گزارش‌های قبلی را اصلاح می‌کند. برای قواعد تطبیق، به اندازه‌گیری تبدیل مراجعه کنید.

۶. چرا داده‌های سامانهٔ مدیریت تبلیغات، ابزار تحلیل و CRM ما با هم تفاوت دارند؟

اقدام‌های یکسان را با قواعد گزارش‌گیری یکسان مقایسه کنید. ممکن است CRM شما همهٔ خریدها را بشمارد؛ گزارش تبلیغاتی، خریدهای منتسب به همان پلتفرم را می‌شمارد. پلتفرم‌های مختلف ممکن است یک خرید واحد را به شکل متفاوتی نسبت دهند.

در سامانهٔ مدیریت تبلیغات، وقتی بازهٔ گزارش‌گیریِ تبدیل پس از مشاهده ۱ روز باشد، تبدیل‌ها شامل مجموع تبدیل‌های پس از کلیک و تبدیل‌های واجد شرایطِ پس از مشاهده است. با بازهٔ مشاهدهٔ ۰ روزه، فقط تبدیل‌های پس از کلیک شمرده می‌شوند. هنگام مقایسهٔ گزارش‌ها از تنظیم یکسان استفاده کنید.

برای مثال، فردی روی تبلیغ کلیک می‌کند، مدتی بعد مستقیماً به سایت برمی‌گردد و خرید می‌کند. ممکن است یک ابزار، بازدید را «مستقیم» برچسب بزند، درحالی‌که ابزار دیگر خرید را به تبلیغ قبلی نسبت می‌دهد. این تفاوت به‌تنهایی به معنای دوبار شمرده‌شدن خرید نیست.

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

این موارد را مقایسه کنید:

  • حساب، کمپین، نوع رویداد، فیلترها و سطح گزارش‌گیری.

  • بازهٔ تاریخ، منطقهٔ زمانی و اینکه تاریخ‌ها به تعامل با تبلیغ اشاره دارند یا به خودِ تبدیل.

  • تنظیمات تبدیل پس از کلیک و پس از مشاهده، و شاخص یا ستون دقیقِ انتخاب‌شده.

  • تأخیرهای اخیر در پردازش، نحوهٔ رسیدگی به موارد تکراری، رضایت کاربر و اطلاعات تطبیقِ در دسترس.

  • تبدیل‌های مدل‌سازی‌شده، در صورت وجود، که ممکن است با تراکنش‌های ثبت‌شدهٔ مستقیم تفاوت داشته باشند.

  • برای مقادیر: ارز، واحدها و اینکه مقایسه بر مبنای کل سفارش است یا تک‌تک اقلام.

برای درآمد، مالیات، هزینهٔ ارسال، تخفیف‌ها و کارمزدها را مقایسه کنید. بررسی کنید نسخه‌های مرورگر و سرور، مبلغ یکسانی برای سفارش ارسال کنند. فروش سفارش‌های ایجادشده و بازده هزینهٔ تبلیغات سفارش‌های ایجادشده فقط رویدادهای order_created منتسب‌شده را در محاسبه لحاظ می‌کنند.

داده‌های فعالیت واردشده از GA4 شامل رویدادهای همهٔ منابع ترافیکِ پراپرتی انتخاب‌شده است. این آمار کل، بیانگر تبدیل‌های منتسب به کمپین نیست. به اتصال Google Analytics 4 به سامانهٔ مدیریت تبلیغات OpenAI مراجعه کنید.

برای مقایسه از طریق API، نقطه پایان را ثبت کنید و گزینه‌های گزارش‌گیری را صریحاً تنظیم کنید. گزینه‌ای که تنظیم نشده است، ممکن است با تنظیم سامانهٔ مدیریت تبلیغات مطابقت نداشته باشد. گزارش‌ها ممکن است رویدادهای متفاوتی را نیز شامل شوند: برخی اهداف کمپین را پوشش می‌دهند، اما سایر اقدام‌های ردیابی‌شده را نه. نبودن یک رویداد در یک گزارش ثابت نمی‌کند که آن رویداد هرگز دریافت نشده است.

برای مقایسهٔ فایل‌های CSV از تنظیمات یکسان استفاده کنید و فایل‌های خروجی را بدون ویرایش نگه دارید. برای نماهای سامانهٔ مدیریت تبلیغات به اندازه‌گیری نتایج و برای گزینه‌های API به گزارش‌گیری مراجعه کنید.

۷. آیا استفاده از پیکسل و CAPI باعث می‌شود خرید دوبار شمرده شود؟

برای جلوگیری از دوبار شمرده‌شدن یک اقدام، در نسخه‌های مرورگر و سرور آن از شناسهٔ پیکسل، نام رویداد و شناسهٔ رویداد یکسان استفاده کنید. فیلد شناسهٔ رویداد در CAPI برابر با id و در پیکسل برابر با event_id است. نام رویداد سفارشی را نیز در هر دو طرف یکسان بگذارید.

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

برای تغییر مقدار یا اطلاعات تطبیقِ رویداد اصلی، نسخه‌ای تکراری از آن ارسال نکنید. پیش از اقدام به اصلاح، نحوهٔ عملکرد شرح‌داده‌شده در مستندات را بررسی کنید. به حذف رویدادهای تکراری مرورگر و سرور مراجعه کنید.

۸. ما از Shopify استفاده می‌کنیم. آیا به یکپارچه‌سازی دیگری نیاز داریم؟

پیش از افزودن یکپارچه‌سازی دیگری، اتصال Shopify خود را بررسی کنید. حساب تبلیغاتی و پیکسل متصل را تأیید کنید، سپس بررسی کنید برنامه کدام رویدادها را برای فروشگاه شما ارسال می‌کند.

اگر از تگ‌های سفارشی، کدِ فرایند پرداخت یا ارسال‌کنندهٔ سمت سرور هم استفاده می‌کنید، بررسی کنید آیا آن‌ها نیز همان رویدادها را ارسال می‌کنند. راه‌اندازی‌های Shopify می‌توانند از ترکیب‌های متفاوتی از ردیابی مرورگر و سرور استفاده کنند. به راه‌اندازی تبلیغات ChatGPT برای Shopify مراجعه کنید.

۹. رضایت کاربران و آزمایش را چگونه مدیریت کنیم؟

فقط داده‌هایی را ارسال کنید که اجازهٔ اشتراک‌گذاری آن‌ها را دارید و به انتخاب‌های بازدیدکنندگان دربارهٔ رضایت احترام بگذارید. توسعه‌دهندهٔ شما باید راهنمای یکپارچه‌سازی دربارهٔ رضایت و داده‌های تطبیقِ پشتیبانی‌شده را رعایت کند، از جمله هرگونه نرمال‌سازی و هش‌کردنِ لازم. برای افزایش تبدیل‌های گزارش‌شده یا بهبود امتیاز، سازوکارهای کنترل رضایت را حذف نکنید.

رضایت برای اندازه‌گیری و opt_out کاربردهای متفاوتی دارند. گزینهٔ opt_out به شخصی‌سازی مربوط است؛ این گزینه همهٔ درخواست‌های اندازه‌گیری را متوقف نمی‌کند. از توسعه‌دهندهٔ خود بخواهید نحوهٔ مدیریت رضایت را در هر دو یکپارچه‌سازی مرورگر و سرور بررسی کند.

زمان، نام و شناسهٔ یک اقدام آزمایشی را ثبت کنید. بررسی کنید آیا ارسال، اعتبارسنجی و دریافت شده است. موفقیت آزمایش پیاده‌سازی نشان نمی‌دهد که تبلیغ واجد شرایط انتساب است.

گزینهٔ validate_only در CAPI رویدادها را بدون ذخیره‌کردن آن‌ها بررسی می‌کند. حالت اشکال‌زدایی پیکسل، فعالیت را در گزارش فنی ثبت می‌کند، اما مانع ورود رویدادهای آزمایشی به گزارش‌ها نمی‌شود. آزمایش‌ها را در سوابق خود برچسب‌گذاری کنید و برای رسیدن به نتیجهٔ دلخواه، خرید ساختگی ایجاد نکنید یا زمان رویدادها را تغییر ندهید.

۱۰. آیا پایین‌بودن یا در دسترس نبودن امتیاز کیفیت رویداد به معنای خرابی ردیابی است؟

به‌تنهایی نه. کیفیت رویداد، اطلاعات دریافت‌شده از یک منبع داده را ارزیابی می‌کند. این معیار به شما نمی‌گوید چه تعداد تبدیل به تبلیغات نسبت داده شده‌اند. پایین‌بودن یا در دسترس نبودن امتیاز، به‌تنهایی نمی‌تواند مشخص کند که ردیابی درست کار می‌کند یا نه.

بررسی کنید اقدام‌های واقعیِ اخیر درست ثبت می‌شوند، سپس هشدار را بررسی کنید. برای بالا بردن امتیاز، رویدادهای اضافی یا شناسه‌های ساختگی ارسال نکنید. برای بررسی‌ها و زمان‌بندی به‌روزرسانی، به درک و بهبود کیفیت رویداد مراجعه کنید.

۱۱. هنگام تماس با پشتیبانی چه اطلاعاتی ارائه کنم؟

به ما بگویید چه انتظاری داشتید، چه اتفاقی افتاد، مشکل از چه زمانی شروع شد و چه چیزهایی را بررسی کردید. از فهرست زیر، هر موردی را که در اختیار دارید ارائه کنید:

  • شناسهٔ حساب تبلیغاتی، شناسهٔ پیکسل یا منبع داده و شناسه‌های کمپین و تبلیغی که مشکل دارند.

  • نوع یکپارچه‌سازی و نام دقیق رویداد، از جمله نام هر رویداد سفارشی.

  • شناسهٔ یک یا دو رویداد موجود به‌عنوان نمونه و مهرهای زمانی اقدام‌ها، همراه با منطقهٔ زمانی.

  • برای درخواست‌های ناموفق یا دریافت نامطمئن: کد پاسخ، متن دقیق خطا، زمان درخواست، هر شناسهٔ درخواست یا CF-Ray بازگشتی، و محتوای درخواست یا بخشی از گزارش فنی با حذف اطلاعات حساس.

  • برای تفاوت گزارش‌ها: بازهٔ تاریخ، مبنای زمانی گزارش‌گیری، تنظیمات انتساب، ستون‌های انتخاب‌شده، خروجی CSV و مقایسه‌ای با دامنهٔ یکسان.

  • نماگرفت‌های مرتبط و هرگونه تغییر اخیر در راه‌اندازی، از جمله فرایند پرداخت جداگانه یا یکپارچه‌سازی با سرویس شریک.

به ما بگویید آیا ارسال، پذیرش یا دریافت رویداد را تأیید کرده‌اید یا فقط گزارش را بررسی کرده‌اید. حتی اگر نمی‌توانید این بررسی‌ها را کامل کنید، می‌توانید درخواست کمک کنید.

کلیدهای API، سرآیندهای مجوزدهی، گذرواژه‌ها، کوکی‌ها و اطلاعات غیرضروری مشتریان را از پیوست‌ها حذف کنید. خطاها یا توقف ناگهانی یکپارچه‌سازی‌ای را که قبلاً کار می‌کرد، بی‌درنگ گزارش دهید. منتظر پایان بازهٔ گزارش‌گیری نمانید.

آیا این مقاله مفید بود؟