رویدادهای فروشگاه اینترنتی را چطور درست بسنجیم؟
نقشهٔ رویدادهای محصول تا خرید را طراحی کنید، مبلغ و کالاها را درست بفرستید و مسیر را پیش از تحلیل با سفارش آزمایشی اعتبارسنجی کنید.
اگر گزارش فروشگاه می‌گوید در یک هفته چند بار کالا به سبد افزوده شده، اما سفارش ثبت‌شده را بیشتر یا کمتر از واقع نشان می‌دهد، تصمیم‌های بعدی هم قابل اعتماد نخواهند بود. ممکن است تبلیغی را متوقف کنید که فروش آورده، یا برای مسیری هزینه کنید که فقط کلیک تولید کرده است. مسئله معمولاً از خود گزارش شروع نمی‌شود؛ از رویدادهایی شروع می‌شود که ناقص، تکراری یا با معنای نادرست به سامانهٔ تحلیل فرستاده می‌شوند.
ثبت رویدادهای فروشگاه اینترنتی در گوگل آنالیتیکس ۴ باید رفتارهای مهم مشتری را به‌شکلی منسجم ثبت کند: دیدن فهرست کالا، مشاهدهٔ محصول، افزودن به سبد، آغاز پرداخت، خرید و بازپرداخت. در این راهنما از طراحی نقشهٔ رویداد تا پارامترهای محصول، جلوگیری از خرید تکراری، آزمون مسیر واقعی و خواندن شاخص‌ها را مرحله‌به‌مرحله مرور می‌کنیم. چارچوب برای فروشگاه‌های مختلف یکسان است؛ شیوهٔ اتصال به هر بستر ممکن است فرق کند.
مستندات رسمی گوگل برای فروشگاه‌ها رویدادهایی برای مشاهدهٔ فهرست و محصول، افزودن یا برداشتن کالا از سبد، شروع پرداخت، خرید، بازپرداخت و تعامل با تخفیف پیشنهاد می‌کند. فرستادن این رویدادها امکان بررسی محبوبیت کالاها و اثر جایگاه محصول یا پیشنهادهای فروش را فراهم می‌کند؛ اما فقط وقتی داده‌ها درست و با رضایت و تنظیمات حریم خصوصی فروشگاه جمع‌آوری شوند. مستندات رسمی سنجش تجارت الکترونیک.
اول تصمیم بگیرید چه چیزی را می‌خواهید بفهمید
نصب یک برچسب اندازه‌گیری به‌تنهایی به شما نمی‌گوید چرا مشتری از خرید منصرف شده است. پیش از تنظیم سامانه، سه تا پنج پرسش بنویسید که پاسخشان به تصمیم اجرایی منجر می‌شود. برای مثال: کدام دسته محصول بیشتری به سبد می‌برد اما خرید کمتری می‌سازد؟ در کدام مرحله از پرداخت مشتریان خارج می‌شوند؟ کدام کمپین مشتری تازه می‌آورد که واقعاً خرید می‌کند؟ چند سفارش پس از پرداخت موفق ثبت می‌شود؟
بعد برای هر پرسش مشخص کنید کدام عمل مشتری پاسخ را می‌سازد، چه اطلاعاتی لازم است و چه تصمیمی با آن می‌گیرید. اگر فقط می‌خواهید تعداد خریدها را بدانید، رویداد خرید و شناسهٔ یکتای سفارش نقطهٔ شروع‌اند. اگر می‌خواهید بفهمید کدام محصول در فهرست نتیجهٔ بهتری دارد، باید نام و شناسهٔ کالا را در مشاهدهٔ فهرست، انتخاب و خرید به یک شکل ثبت کنید. بدون این پیوند، رویدادها جدا از هم می‌مانند.
از ابتدا مسئول هر بخش را تعیین کنید: توسعه‌دهنده یا مدیر فروشگاه که رویداد را ایجاد می‌کند، کسی که سامانهٔ تحلیل را تنظیم می‌کند و فردی که سفارش آزمایشی را انجام می‌دهد. در فروشگاه کوچک ممکن است همهٔ این نقش‌ها یک نفر باشند؛ مهم این است که پیش از انتشار معلوم باشد چه کسی مبلغ و محتویات سفارش را با دادهٔ دریافتی تطبیق می‌دهد.
نقشهٔ مسیر خرید و نام رویدادها را استاندارد کنید
یک جدول ساده بسازید که در هر ردیف، رویداد، لحظهٔ اجرا، صفحه یا کنش محرک، داده‌های لازم و روش آزمون را ثبت کند. نام‌های پیشنهادی گوگل را همان‌طور که هستند به‌کار ببرید. برای نمونه، مشاهدهٔ صفحهٔ محصول را با view_item، افزودن موفق به سبد را با add_to_cart، آغاز پرداخت را با begin_checkout و سفارش تکمیل‌شده را با purchase ثبت کنید. برای مشاهده و انتخاب از فهرست، به‌ترتیب view_item_list و select_item مناسب‌اند.
نام‌گذاری دلخواه مثل add_to_basket ممکن است برای گزارش ساده قابل خواندن باشد، اما به رویداد پیشنهادی یکسان نیست و گزارش‌های استاندارد و پیشنهادهای سامانه را از دست می‌دهد. از سوی دیگر، رویداد را صرفاً به‌خاطر بازشدن صفحه نفرستید. رویداد افزودن به سبد باید پس از آن ثبت شود که کالا واقعاً وارد سبد شد؛ کلیک روی دکمه‌ای که خطا داده یا موجودی ندارد، افزودن موفق نیست.
یک نقشهٔ شروع می‌تواند چنین باشد:
| مرحله | رویداد پیشنهادی | زمان ثبت | اطلاعات کلیدی |
|---|---|---|---|
| نمایش فهرست | view_item_list | فهرست کالاها دیده شد | شناسه و نام فهرست، کالاهای نمایش‌داده‌شده |
| مشاهدهٔ محصول | view_item | جزئیات محصول باز شد | شناسه، نام، قیمت، گونه و دستهٔ کالا |
| افزودن به سبد | add_to_cart | افزودن موفق تأیید شد | کالا، تعداد، قیمت و مبلغ کالاهای افزوده‌شده |
| شروع پرداخت | begin_checkout | مشتری وارد نخستین گام پرداخت شد | محتویات سبد، مبلغ و کد تخفیف |
| ثبت خرید | purchase | سفارش با وضعیت پرداخت موفق تأیید شد | شناسهٔ سفارش، مبلغ، واحد پول و اقلام خریداری‌شده |
در صورت داشتن مراحل جداگانه، انتخاب روش ارسال و روش پرداخت را نیز با رویدادهای پیشنهادی مربوط ثبت کنید. نام و زمان باید با معنای واقعی صفحهٔ شما جور باشد؛ برای مثال اگر انتخاب ارسال در یک گام انجام می‌شود و پرداخت در مرحلهٔ بعد، هر دو را می‌توان مستقل بررسی کرد. نقشه را با روند واقعی تسویه تطبیق دهید، نه با یک الگوی عمومی که با فروشگاه شما سازگار نیست.
اطلاعات کالا و مبلغ را یک‌دست بفرستید
رویدادهای تجارت الکترونیک معمولاً دو سطح داده دارند: اطلاعات کل سفارش و اطلاعات هر قلم. در سطح سفارش، بسته به رویداد، مبلغ، واحد پول، کد تخفیف، مالیات، هزینهٔ ارسال و شناسهٔ تراکنش قرار می‌گیرد. در آرایهٔ کالاها، شناسه یا نام کالا ضروری است و بهتر است هر دو را بفرستید؛ قیمت، تعداد، گونه یا رنگ، برند و دسته هم برای گزارش دقیق‌تر مفیدند.
شناسهٔ کالا باید میان فهرست، صفحهٔ محصول، سبد و سفارش ثابت بماند. اگر یک جا شناسهٔ مدل و جای دیگر شناسهٔ محصول مادر فرستاده شود، سامانه ممکن است آن‌ها را دو کالای متفاوت ببیند. برای کالاهای چندمدلی، تصمیم بگیرید آیا گزارش باید بر پایهٔ محصول اصلی باشد یا گونهٔ خریداری‌شده؛ سپس شناسهٔ محصول و گونه را در فیلدهای جدا و با قاعدهٔ ثابت ثبت کنید.
پارامتر مبلغ را مطابق تعریف فروشگاه محاسبه کنید. ارزش اقلام معمولاً از جمع قیمت پس از تخفیف هر کالا ضرب‌در تعداد ساخته می‌شود. هزینهٔ ارسال و مالیات را در پارامترهای جداگانه بفرستید تا با ارزش کالا اشتباه نشوند. منطق گزارش داخلی مالی و گزارش تحلیلی ممکن است در احتساب مالیات، ارسال، لغو یا بازپرداخت دقیقاً یکسان نباشد؛ تعریف خود را ثبت کنید تا مقایسه‌ها را با یک مبنا انجام دهید.
شناسهٔ سفارش را برای تطبیق رویدادها با تراکنش فروشگاه در اختیار سامانه بگذارید، اما نام، نشانی ایمیل، شمارهٔ تلفن یا متن آزاد واردشده در فرم را به‌عنوان پارامتر تحلیلی نفرستید. همچنین شناسهٔ مشتری را طوری انتخاب نکنید که به‌تنهایی فرد را بشناسد؛ برای داده‌های کاربر، قواعد خود سامانه و سیاست حریم خصوصی را جداگانه بررسی کنید. گوگل تصریح می‌کند که اطلاعاتی مانند ایمیل و شمارهٔ تلفن نباید به داده‌های گوگل آنالیتیکس فرستاده شوند؛ نشانی صفحه و پارامترهای آن هم باید از اطلاعات شخصی پاک باشند. راهنمای رسمی پرهیز از ارسال اطلاعات هویتی.
اگر مقدار عددی شما به تومان است، آن را بی‌تبدیل با کد ریال معرفی نکنید. کد واحد پول باید با عددی که فرستاده‌اید سازگار باشد؛ در غیر این صورت گزارش ممکن است یک سفارش را ده برابر یا یک‌دهم ارزش واقعی نشان دهد. پیش از راه‌اندازی، یک سفارش آزمایشی کوچک بسازید و مبلغ اقلام، تخفیف، ارسال و مالیات را با رسید همان سفارش مقایسه کنید. مستندات گوگل توصیه می‌کند هنگام ارسال مقدار درآمد، واحد پول تراکنش نیز در سطح رویداد مشخص باشد. جزئیات پارامترهای رویداد و واحد پول.
خرید را فقط پس از تأیید واقعی سفارش ثبت کنید
مهم‌ترین رویداد فروش، نقطه‌ای است که بیشترین خطای مالی می‌تواند در آن رخ دهد. رویداد خرید را پس از ثبت قطعی سفارش و تأیید وضعیت موفق پرداخت ارسال کنید، نه با کلیک روی دکمهٔ پرداخت و نه در هر بار بازشدن صفحهٔ تشکر. اگر سفارش درگاه ناموفق بوده، یا مشتری صفحهٔ تأیید را دوباره بارگذاری کرده، نباید خرید تازه‌ای به گزارش اضافه شود.
برای هر سفارش یک شناسهٔ یکتای تراکنش بفرستید و در سمت فروشگاه نیز جلوی ارسال دوباره را بگیرید. صفحهٔ تشکر ممکن است با بازگشت کاربر، بارگذاری دوباره، مرورگرهای مختلف یا بازشدن دوبارهٔ لینک دیده شود. رویداد خرید باید از وضعیت سفارش یا یک رسید امن تغذیه شود و برای یک شناسهٔ سفارش بیش از یک بار در مسیر عادی ایجاد نشود. مستندات رسمی اعتبارسنجی، شناسه‌های تراکنش تکراری و نصب چندبارهٔ برچسب را از علت‌های رایج از دست‌رفتن یا دوباره‌شماری رویدادها می‌شمارد. راهنمای اعتبارسنجی و رفع خطاهای رویداد.
رویداد بازپرداخت را هم در برنامهٔ اندازه‌گیری در نظر بگیرید. وقتی وجه یا بخشی از سفارش بازپرداخت شد، با همان شناسهٔ تراکنش و در صورت امکان با اقلام و تعداد برگشتی، رویداد مرتبط را ارسال کنید. این کار کمک می‌کند تحلیل درآمد صرفاً به ثبت خرید اولیه محدود نماند و اثر برگشت وجه یا کالا هم در بررسی دیده شود.
چطور رویدادهای خرید را آزمایش کنید؟
پیش از راه‌اندازی عمومی، یک سفارش آزمایشی را روی همان مسیر مشتری انجام دهید. اگر درگاه آزمایشی یا روش امنی برای سفارش کم‌مبلغ دارید، از آن استفاده کنید و برای اینکه گزارش اصلی را آلوده نکند، طبق روش تیم خود دادهٔ آزمایشی و ترافیک توسعه‌دهنده را از گزارش عملیاتی جدا نگه دارید. هدف، بررسی مرحله‌به‌مرحلهٔ رویدادها و پارامترهاست، نه ساختن درآمد مصنوعی.
- حالت اشکال‌زدایی را برای دستگاه آزمایشی فعال کنید.
- یک فهرست را باز کنید و ببینید فهرست و کالاهای واقعاً دیده‌شده ارسال می‌شوند.
- یک محصول را باز کنید و شناسه، نام و قیمت آن را بررسی کنید.
- کالایی را به سبد بیفزایید، تعداد را تغییر دهید و در صورت پشتیبانی، یک کالا را حذف کنید.
- پرداخت را تا رسیدن به سفارش موفق انجام دهید و خرید را در نمای اشکال‌زدایی بررسی کنید.
- شناسهٔ سفارش، واحد پول، مبلغ، تخفیف و آرایهٔ اقلام را با رسید تطبیق دهید.
- صفحهٔ تأیید را دوباره باز کنید تا مطمئن شوید سفارش تکراری ثبت نمی‌شود.
- یک حالت لغو یا پرداخت ناموفق را نیز جداگانه آزمایش کنید تا رویداد خرید اشتباهی ایجاد نشود.
در نمای اشکال‌زدایی می‌توانید ببینید هر رویداد چه پارامترهای سطح رویداد و چه داده‌های سطح کالا فرستاده است. این ابزار به حالت اشکال‌زدایی نیاز دارد و برخی تنظیمات رضایت یا کنترل حریم خصوصی ممکن است مانع نمایش رویداد شوند. اگر رویداد دیده نمی‌شود، نام پیشنهادی، ترتیب بارگذاری برچسب، خطای جاوااسکریپت و تنظیمات رضایت را بررسی کنید. راهنمای گوگل استفاده از نمای اشکال‌زدایی را برای مشاهدهٔ رویدادهای دریافتی و عیب‌یابی توصیه می‌کند. راهنمای رسمی نمای اشکال‌زدایی.
خطاهای رایجی که گزارش فروش را گمراه می‌کنند
- نام رویدادهای دلخواه: انتخاب نام نزدیک اما نادرست، استفاده از گزارش‌ها و قابلیت‌های استاندارد را دشوار می‌کند.
- ثبت خرید در بارگذاری صفحه: بازدید دوباره از رسید ممکن است سفارش را دوباره بشمارد؛ خرید را به وضعیت قطعی سفارش و شناسهٔ یکتا گره بزنید.
- نصب هم‌زمان دو برچسب: افزودن مستقیم برچسب و نصب دوباره از طریق مدیر برچسب می‌تواند چند رویداد مشابه تولید کند.
- کد ارز ناهماهنگ با واحد مبلغ: ثبت مبلغ تومان با کد ریال یا برعکس، مقدار درآمد را تحریف می‌کند.
- شناسهٔ کالاهای متغیر و ناسازگار: یکسان‌نبودن شناسه در صفحه و سفارش، گزارش محصول را تکه‌تکه می‌کند.
- ثبت کلیک به‌جای نتیجه: کلیک دکمهٔ افزودن یا پرداخت، معادل موفقیت عمل نیست؛ رویداد را پس از تأیید وضعیت واقعی ثبت کنید.
- بی‌توجهی به بازپرداخت و لغو: خرید اولیه را بدون اصلاحات بعدی به‌عنوان درآمد نهایی تفسیر نکنید.
شاخص‌هایی که پس از پیاده‌سازی معنا پیدا می‌کنند
وقتی رویدادها و شناسهٔ کالاها قابل اتکا شدند، می‌توانید نسبت‌های ساده‌ای بسازید: تعداد سفارش به تعداد آغاز پرداخت، تعداد خرید به تعداد افزودن به سبد، و درآمد یا تعداد اقلام به تفکیک کالا و منبع ورودی. نرخ خروج میان دو مرحله را همیشه با تعریف روشن و بازهٔ یکسان محاسبه کنید. برای نمونه، افت میان افزودن به سبد و شروع پرداخت می‌تواند نشان دهد که مشتری در سبد با هزینهٔ ارسال یا شرط تازه‌ای روبه‌رو شده است؛ اما پیش از نتیجه‌گیری، تفاوت دستگاه، منبع ورودی و کیفیت داده را هم بررسی کنید.
برای تحلیل مسیر، گزارش‌ها را کنار قیف واقعی فروشگاه بگذارید. راهنمای تحلیل قیف فروش کمک می‌کند افت هر مرحله را به پرسش اجرایی تبدیل کنید. اگر در پرداخت ریزش می‌بینید، با مقالهٔ بهینه‌سازی فرایند پرداخت گام‌های آزمایش را انتخاب کنید. برای دیدن تغییر رفتار ناشی از صفحه یا پیام، نتیجه را با راهنمای آزمایش نسخه‌های مختلف فروشگاه بسنجید؛ اما ابتدا مطمئن شوید خریدها دوبار شمرده نمی‌شوند.
از رویدادهای معتبر تا گزارش قابل تصمیم‌گیری
پس از بررسی اولیه، برای هر گزارش بازهٔ زمانی و مخرج شاخص را مشخص کنید. برای مثال، نسبت خرید به شروع پرداخت را در یک بازهٔ یکسان و برای یک گروه ثابت از بازدیدکنندگان بسنجید؛ تعداد خرید به تعداد کاربر با تعداد خرید به تعداد نشست یکی نیست. تغییر تعریف مخرج، روند را جابه‌جا می‌کند بی‌آنکه رفتار مشتری تغییر کرده باشد.
شناسهٔ کمپین یا منبع ورود را با قرارداد نام‌گذاری ثابت ثبت کنید و آن را کنار مرحلهٔ قیف ببینید. اگر رویداد خرید معتبر است اما گزارش منبع‌ها ناقص‌اند، مسئله ممکن است به برچسب‌گذاری لینک، تغییر دامنه در پرداخت یا تنظیم انتساب مربوط باشد. در این حالت نتیجه‌گیری دربارهٔ برندهٔ کمپین را تا زمان رفع مشکل عقب بیندازید. اول کیفیت جمع‌آوری داده را ثابت کنید؛ بعد دربارهٔ تغییر تجربهٔ خرید تصمیم بگیرید.
رویدادهای تحلیلی نیز تابع رضایت و انتخاب‌های حریم خصوصی کاربرند. اگر ابزار مدیریت رضایت دارید، رفتار آن را در حالت پذیرش و رد جداگانه آزمایش کنید و مطمئن شوید گزارش تست توسعه با دادهٔ مشتریان واقعی مخلوط نمی‌شود. نبودن رویداد برای کاربری که اجازهٔ اندازه‌گیری نداده، لزوماً خطای فنی نیست؛ آن را با تنظیمات و الزامات محل فعالیت فروشگاه تطبیق دهید.
چک‌لیست اجرایی
- پرسش‌های تجاری را مشخص و هر پرسش را به رویداد یا گزارش لازم وصل کنید.
- نقشهٔ رویداد را با نام‌های پیشنهادی و زمان اجرای واقعی تهیه کنید.
- شناسه و نام محصول، گونه، قیمت و تعداد را در همهٔ مراحل یکسان نگه دارید.
- تعریف مبلغ، تخفیف، مالیات، ارسال و واحد پول را با تیم مالی هماهنگ کنید.
- رویداد خرید را فقط پس از تأیید سفارش موفق بفرستید و شناسهٔ تراکنش یکتا داشته باشید.
- بررسی کنید در هر صفحه فقط یک مسیر اصلی نصب برچسب فعال است.
- با سفارش آزمایشی موفق، ناموفق، بازشدن دوبارهٔ رسید و بازپرداخت را بررسی کنید.
- در نمای اشکال‌زدایی هم نام رویداد و هم پارامترهای سطح سفارش و کالا را ببینید.
- یک سفارش واقعی را با دادهٔ گزارش‌شده تطبیق دهید و اختلاف را پیش از تحلیل پیدا کنید.
- تنها پس از اعتبارسنجی، شاخص‌های قیف، درآمد و محصول را برای تصمیم‌گیری به کار ببرید.
جمع‌بندی
اندازه‌گیری قابل‌اعتماد از گزارش شروع نمی‌شود؛ از تعریف دقیق رویداد، شناسه و مبلغی آغاز می‌شود که فروشگاه می‌فرستد. اگر افزودن به سبد تنها پس از موفقیت ثبت شود، اگر رویداد خرید به سفارش قطعی و شناسهٔ یکتا متصل باشد و اگر ارز و اقلام با رسید هماهنگ باشند، گزارش می‌تواند مسیر واقعی خرید را روشن‌تر کند.
یک فروشگاه لازم نیست همهٔ رویدادها و پارامترها را در روز اول پیاده کند. از پرسش‌های مهم شروع کنید، مسیر را با چند سفارش آزمایشی اعتبارسنجی کنید و خطاهای دوباره‌شماری و واحد پول را برطرف کنید. بعد می‌توانید با اطمینان بیشتری بفهمید مشتری کجا منصرف می‌شود و کدام اصلاح احتمالاً ارزش بررسی دارد.
منابع و راهنماهای تکمیلی
- رویدادها و پارامترهای تجارت الکترونیک در گوگل آنالیتیکس، مستندات توسعه‌دهندگان گوگل.
- اعتبارسنجی و عیب‌یابی پیاده‌سازی تجارت الکترونیک، مستندات توسعه‌دهندگان گوگل.
- مشاهدهٔ رویدادها در نمای اشکال‌زدایی، راهنمای رسمی گوگل.
