گزارشگیری GA4 برای سایتهای چندزبانه: تحلیل قیف بر اساس نسخه زبانی
بُعد Language در GA4 زبان مرورگر را میسنجد، نه نسخه سایت را. راهاندازی custom dimension، ساخت Funnel Exploration و تمرین گزارشدهی قیف زبانی.
نوشته Roozbeh Nazari · CEO
در سایت چندزبانه، گزارشهای پیشفرض GA4 یک استخر واحد نشانتان میدهد: همه زبانها، همه بازارها، یک منحنی. جمله «سایت خوب پیش میرود» روی همین استخر ساخته میشود و خطرناک است؛ عملکرد قوی ترکی میتواند ماهها قیف عربیِ در حال نشت را پنهان کند. برای تصمیم در سطح بازار، واحد پایه گزارش نه خود نشست، بلکه این است که نشست در کدام نسخه زبانی گذشته. این مقاله ساخت تحلیل قیف بر اساس زبان در GA4 را سرتاسری توضیح میدهد: با کدام بُعد، کدام رویدادها و کدام گزارشها.
از اولین و رایجترین تله شروع کنیم: بُعد آماده «Language» در GA4 زبان مرورگر کاربر را میسنجد، نه نسخه زبانی سایت شما را. کاربری در دبی که با مرورگر انگلیسی بخش /ar/ را میگردد، در این بُعد انگلیسی دیده میشود. هر دو اطلاع ارزشمندند اما به دو سؤال متفاوت جواب میدهند؛ زبان مرورگر پروفایل زبانی مخاطب را توصیف میکند، نسخه سایت میگوید کدام تجربه تبدیل میسازد. تحلیل قیف دومی را میخواهد و GA4 خودش آن را نمیداند — باید زبان سایت را خودتان به اندازهگیری اضافه کنید. خبر خوب: راهاندازیای است که در یک بعدازظهر جا میشود. خبر بد: گزارش ماههایی که نبود، عطف به ماسبق درست نمیشود، چون GA4 داده را با بُعدهای روز جمعآوری نگه میدارد.
دو مسیر عملی هست. اولی content grouping: پارامتر content_group را که از پیشوند زبان در مسیر صفحه (/tr/، /en/) مشتق میشود به پیکربندی اضافه میکنید؛ «گروه محتوا» در گزارشهای صفحه بهعنوان بُعدی آماده ظاهر میشود. راهاندازیاش چند خط است و برای تحلیلهای صفحهمحور کافی است. محدودیتش: content group به مفهوم بازدید صفحه گره خورده و هنگام برشزدن مراحل رویدادمحور مثل ارسال فرم یا کلیک WhatsApp انعطافش پایین میآید.
مسیر دوم — که توصیه ماست — یک custom dimension در سطح رویداد است که به همه رویدادها اضافه میشود: site_locale. در Tag Manager متغیری تعریف میکنید که از مسیر URL یا از مقدار html lang صفحه خوانده میشود و بهصورت پارامتر به همه رویدادها — از بازدید صفحه تا ارسال فرم — اضافه میگردد. بعد در Admin، بخش Custom definitions، همان site_locale را ثبت میکنید؛ پارامتر ثبتنشده هرگز در گزارشها دیده نمیشود و این قدم، فراموششدهترین حلقه است. پراپرتیهای استاندارد به پنجاه بُعد سفارشی سطح رویداد محدودند؛ خرجکردن دائمی یک جایگاه برای زبان، از بهترین مصرفهای این سهمیه در سایت چندزبانه است. با این راهاندازی، هر مرحله قیف — از هر رویدادی که بیاید — بر اساس نسخه زبانی قابل برش میشود. در سمت GTM هم متغیر چیز پیچیدهای نمیخواهد: یک متغیر کوچک JavaScript که اولین بخش مسیر صفحه را میخواند یا یک lookup table با همان کار، کافی است؛ مهم این است که مقدارها همهجا از یک واژهنامه بیایند.
وقتی بُعد آماده شد، نوبت خود قیف است. یک اسکلت واقعبینانه برای سایت خدماتمحور: شروع نشست، بازدید صفحه خدمت، نیت تعامل (form_start یا کلیک دکمه WhatsApp)، ارسال (generate_lead). این مراحل نامگذاری رویداد یکدست میخواهند و آنچه تبدیل محسوب میشود باید در GA4 بهعنوان key event علامت بخورد. سپس در Explore یک Funnel Exploration بسازید: مراحل همین رویدادها، بُعد تفکیک site_locale. گزینه نمایش زمان بین مراحل را هم روشن کنید؛ تفاوت سرعت تصمیم بین بازارها اغلب آموزندهتر از تفاوت نرخ تبدیل است. مراقب باشید تعریف مراحل بین زبانها یکسان بماند؛ اگر یک زبان فرممحور و دیگری WhatsAppمحور است، قالب قیف را بر وجه مشترک بسازید و مراحل خاص هر کانال را در نمایی جدا بررسی کنید. کنار هم گذاشتن دو قیف با دو تعریف متفاوت، مقایسه نیست، توهم میسازد.
یک نکته ظریف: کاربران بین نسخههای زبانی جابهجا میشوند. کاربری که روی صفحه انگلیسی فرود میآید و در صفحه عربی فرم میفرستد استثنا نیست. site_locale در سطح رویداد دقیقاً برای همین انتخاب درستی است؛ هر مرحله را در نسخهای که رخ داده ثبت میکند و جابهجاییها را دیدنی میسازد. کنارش یک نمای نقطه ورود هم بگذارید: خواندن بُعد صفحه فرود همراه زبان نشان میدهد کدام زبان ترافیک میآورد. دو سؤال را آگاهانه جدا کنید: «کدام زبان بازدیدکننده میآورد» سؤالی مارکتینگی است، «کدام نسخه زبانی متقاعد میکند» سؤالی تجربهمحور؛ گزارشی که این دو را در یک معیار قاتی کند، به هر دو غلط جواب میدهد.
چون تحلیل زبانی داده را تقسیم میکند، با واقعیت اعداد کوچک هم روبرو میشوید. در پراپرتیهایی که Google Signals فعال است آستانههای گزارش وارد میشوند و در بخشهای کوچک ردیفها پنهان میشوند؛ در بازه تاریخی تنگ، قیف عربی شما ممکن است تا حدی خالی دیده شود. راه حل گشادکردن پنجره است: بهجای روزانه هفتگی، و اگر لازم شد ماهانه نگاه کنید و نرخها را بهصورت روند بخوانید، نه روزهای منفرد. اگر ارزش را بین بازارها مقایسه میکنید، مطمئن شوید پارامتر currency در هر بازار درست ارسال میشود؛ GA4 ارزشها را به ارز گزارش پراپرتی تبدیل میکند اما ارز غلط برچسبخورده را جای شما تصحیح نمیکند.
بُعد زبان، وقتی با سمت پولی ترکیب شود قدرت واقعیاش را نشان میدهد. اطلاع زبان را در نامگذاری کمپینها و انضباط UTM استاندارد کنید؛ آنوقت وقتی گزارش منبع/رسانه را با site_locale چپ میکنید، میبینید تبلیغ کدام بازار روی کدام نسخه زبانی فرود میآید. اولین خطایی که این نگاه چپی میگیرد تقریباً همیشه یکی است: ترافیک تبلیغاتی که روی زبان اشتباه فرود میآید. سوانح ناهمخوانی مثل فرود کمپین عربیهدف روی صفحه انگلیسی، در بالای قیف بیسروصدا بودجه میسوزاند. همچنین مخاطبان (audience) GA4 فیلترشده با site_locale بسازید و فهرستهای ریمارکتینگ را به تفکیک بازار جدا کنید؛ ریمارکتینگ از استخر واحد، کوتاهترین راه نمایش آگهی به زبان اشتباه به کاربر است.
حلقه آخر گزارشدهی، گذاشتن منظم این تحلیل جلوی تصمیمگیرنده است. یک نمای تکصفحهای در Looker Studio برای بیشتر تیمها کافی است: زبانها در سطرها، مراحل قیف در ستونها، کنارش نرخ عبور مراحل و روند هفتگی. برای کسانی که ترجیح میدهند داخل GA4 بمانند، قابلیت comparisons جایگزین سریعی است. یک لایه هشدار زودهنگام هم پیشنهاد کنید: اگر در یک زبان رویدادهای ارسال به صفر برسد، علت معمولاً مارکتینگ نیست، ترجمهای است که شکسته یا اعتبارسنجی فرمی که از کار افتاده؛ ساختن هشدار برای این ناهنجاریها با custom insights در GA4، مشکل را قبل از گزارش هفتگی میگیرد. بالای صفحه گزارش هم تازگی داده و تاریخ آخرین راستیآزمایی را بنویسید؛ بزرگترین ریسک داشبوردی که کسی نگاهش نمیکند، داده غلط نیست، این است که کسی متوجه خرابشدنش نشود.
هشدار میدانی پایانی: اندازهگیری چندزبانه سیستمی نیست که یک بار راه بیفتد، سیستمی است که پیوسته راستیآزمایی میشود. هر دیپلوی، هر تغییری که به کانتینر GTM دست میزند و هر نسخه زبانی تازه، میتواند زنجیره site_locale را بیسروصدا بشکند — و اولین جایی که متوجه میشود معمولاً یک گزارش نیست، جلسه بودجه چند ماه بعد است. در خدمات تحلیل داده SEO Evaluate اندازهگیری چندزبانه را در مرحله راهاندازی رها نمیکنیم؛ با یک روتین راستیآزمایی منظم کنار هم ادارهاش میکنیم. اصل ساده است: اول اندازهگیریای که هر بازار را جدا ببیند، بعد تصمیم بودجه. سایت چندزبانهای که با داده استخری اداره میشود، در واقع اصلاً اداره نمیشود.