افزایش تبدیل سایت شرکتی: اندازهگیری مسیر از صفحه تا تماس
7 دقیقه مطالعه

راهنمای اندازهگیری مسیر بازدید تا سرنخ در سایت شرکتی: event و key event در Google Analytics، رویدادهای مسیر، کیفیت lead، محدودیت attribution و حریم خصوصی بدون وعدهٔ رشد.
«بازدید داریم ولی تماس نداریم» شکایتی رایج در سایتهای شرکتی است. پیش از تغییر طراحی یا افزایش بودجه، باید مسیر کاربر از صفحه تا تماس را اندازه بگیرید تا بدانید کجا گم میشود. این مقاله روش اندازهگیری را با تکیه بر مستندات رسمی Google Analytics (خواندهشده ۱۹ اکتبر ۲۰۲۶) توضیح میدهد: تعریف event و key event، طراحی رویدادهای مسیر، کیفیت سرنخ، محدودیتهای attribution و ملاحظات حریم خصوصی. طرح رویدادها و جدول تشخیص از نویسنده است؛ هیچ نرخ تبدیل یا وعدهٔ رشدی داده نمیشود. نکتهٔ حقوقی: قوانین حریم خصوصی کشورها متفاوت است و این مقاله نظر حقوقی نمیدهد (مستند Google هم در صورت تردید مشورت با وکیل را توصیه میکند). برای زمینهٔ سئو و ترافیک SEO در سال ۲۰۲۶ را ببینید.
event و key event
طبق Analytics Help، event تعامل یا اتفاق مشخصی را میسنجد (بارگذاری صفحه، کلیک لینک، تکمیل خرید). انواع آن: خودکار، enhanced measurement، recommended (نام و پارامتر از پیشتعیینشده) و custom. مستند میگوید custom event را فقط وقتی بسازید که رویداد دیگری مناسب نیست و چون در بیشتر گزارشهای استاندارد نمیآید، گزارش سفارشی یا exploration لازم دارد. key event رویدادی است که عملی مهم برای موفقیت کسبوکار را میسنجد؛ هر رویداد جمعشدهای میتواند key event شود و ستون Key events در گزارشهایی مثل Landing pages و User acquisition نشان داده میشود. برای سایت شرکتی، key event معمولاً «ارسال فرم تماس»، «کلیک روی شمارهٔ تماس» یا «درخواست مشاوره» است.
رویدادهای مسیر (پیشنهاد نویسنده)
| مرحله | رویداد پیشنهادی | پرسشی که پاسخ میدهد |
|---|---|---|
| ورود | page_view (خودکار) با صفحهٔ فرود | کاربر از کدام صفحه وارد میشود؟ |
| علاقه | مشاهدهٔ صفحهٔ خدمات یا نمونهکار | آیا از مقاله به صفحهٔ تجاری میرسد؟ |
| قصد | شروع فرم یا کلیک روی دکمهٔ تماس | چقدر به تماس نزدیک میشود؟ |
| اقدام | ارسال فرم موفق (key event) | چه کسانی تماس را کامل میکنند؟ |
| کیفیت | ثبت واجد شرایطبودن سرنخ در CRM یا فایل | کدام صفحهها سرنخ مناسب میآورند؟ |
نام و تعداد رویدادها را کم و دقیق نگه دارید: رویدادهای زیاد و نامنظم تحلیل را سخت میکنند. اگر رویداد recommended مناسب هست، از همان نام استفاده کنید.

راستیآزمایی پیادهسازی
Analytics Help دو ابزار برای تأیید جمعآوری معرفی میکند: گزارش Realtime که رویدادهای ۳۰ دقیقهٔ اخیر و پارامترهایشان را نشان میدهد، و DebugView که همهٔ رویدادهای یک کاربر را در حالت debug نشان میدهد. پیش از اتکا به داده، فرم را خودتان با DebugView آزمایش کنید و ببینید key event یک بار ثبت میشود. مستند همچنین از ارسال دستهای رویدادها و محدودیت اندازهٔ درخواست (۱۶ کیلوبایت) سخن میگوید؛ پس انتظار داشته باشید داده با واقعیت لحظهای کاملاً یکی نباشد و هنگام بررسی، تأخیرهای کوچک را خطا نپندارید.
کیفیت سرنخ، نه فقط تعداد
افزایش تعداد فرم بدون کیفیت ارزش ندارد. شاخص کیفیت را در دادهای ثبت کنید که خودتان دارید: آیا سرنخ واجد شرایط بود؟ به مشتری تبدیل شد؟ این اطلاعات معمولاً در CRM یا یک فایل ساده است و میتوان آن را به صفحهٔ فرود یا کانال نسبت داد. اما اطلاعات شخصی را به Analytics نفرستید (بخش بعد). این رویه پیشنهاد نویسنده است و نتیجهٔ آن به داده و کسبوکار شما بستگی دارد.
محدودیتهای attribution
Analytics Help میگوید گزارشهای Pathing و Attribution اعتبار را به touchpointها اختصاص میدهند و مدلهای attribution مختلف اعتبار را متفاوت توزیع میکنند. پس عدد «این کانال این تعداد تماس آورد» به مدل وابسته است. برای تصمیم، چند مدل یا چند نگاه را مقایسه کنید و عدد را قطعی نکنید. در B2B با چرخهٔ خرید بلند، کاربر ممکن است ابتدا مقاله بخواند، بعد دوباره از جستوجوی برند بیاید؛ اتصال آنها ساده نیست.
حریم خصوصی
سیاستهای Google ارسال دادهای را که قابل تشخیص بهعنوان PII باشد ممنوع میکند؛ PII شامل نشانی ایمیل و شمارهٔ تلفن است. مستند توصیه میکند URL و عنوان صفحه، فیلدهای فرم و جستوجوی داخلی، dimensionهای سفارشی، پارامترهای utm و dimensionهای رویداد را از PII پاک نگه دارید و از data redaction برای حذف ایمیل و پارامترهای مشخص استفاده کنید. در عمل: پارامترهای رویداد «ارسال فرم» نباید نام یا ایمیل کاربر باشد و آدرس صفحهٔ تشکر نباید حاوی اطلاعات شخصی باشد. اینکه چه چیزی از نظر قانونی در ایران یا هر کشور دیگری PII یا داده شخصی حساب میشود و چه رضایتی لازم است در این مقاله بررسی نشده؛ مستند Google هم میگوید در صورت تردید با وکیل مشورت کنید.
تشخیص: کجای مسیر گم میشود؟
- ترافیک به صفحههای تجاری میرسد یا فقط به مقالهها؟ (Landing pages و مسیر)
- کسانی که به صفحهٔ خدمات میرسند فرم را شروع میکنند؟
- فرم شروعشده کامل میشود؟ (ایراد در طول یا خطای فرم؟)
- سرنخها واجد شرایطاند؟ (ایراد در جذب مخاطب نامناسب؟)
- داده درست جمع میشود؟ (DebugView و آزمون دستی)
پاسخ هر پرسش، نقطهٔ اقدام را نشان میدهد. مثلاً اگر فرم شروع میشود ولی تمام نمیشود، فرم را ساده کنید و دوباره بسنجید؛ اگر ترافیک از مقاله به خدمات نمیرسد، لینک داخلی و متن لینک را بازنگری کنید.
مثال ساختگی
سایت فرضی ماهانه صدها بازدید دارد اما فرم کم پر میشود. پس از افزودن رویدادهای مسیر میبیند بیشتر بازدیدکنندگان فقط مقاله میخوانند و به صفحهٔ خدمات نمیروند. تیم لینکهای توصیفی از مقالهها به صفحهٔ خدمات اضافه میکند، فرم را کوتاه میکند و بعد از چند هفته بازهٔ برابر را مقایسه میکند. اعداد در مثال ساختگیاند و هیچ وعدهٔ رشدی ندارند.
اشتباهات رایج
- تکیه بر ترافیک بهجای key event و کیفیت سرنخ.
- ساخت رویدادهای custom زیاد و بینظم.
- ارسال ایمیل یا تلفن کاربر در پارامتر رویداد یا URL.
- باور به عدد یک مدل attribution.
- تغییر طراحی بدون ثبت داده قبل و بعد.
- نادیدهگرفتن راستیآزمایی با DebugView.
ریتم بازبینی
اندازهگیری وقتی ارزش دارد که بازبینی منظم داشته باشد. پیشنهاد نویسنده: هر ماه یک جلسهٔ کوتاه برگزار کنید و فقط سه چیز را ببینید: تعداد key event به تفکیک صفحهٔ فرود، نسبت سرنخهای واجد شرایط به کل، و تغییرهای انجامشده از جلسهٔ قبل. هر تغییر را با تاریخ ثبت کنید تا بعداً بتوانید دورهٔ قبل و بعد را مقایسه کنید.
در مقایسه مراقب فصلها، کمپینها و رویدادهای بیرونی باشید؛ نوسانهای طبیعی ممکن است با اثر تغییر شما اشتباه گرفته شود. اگر داده کم است، نتیجهگیری قطعی نکنید و بهجای آن فرضیه را برای یک دورهٔ دیگر نگه دارید. همچنین اگر ساختار رویدادها را عوض میکنید، این را در یادداشتها بنویسید، چون مقایسهٔ دو دورهٔ با تعریفهای متفاوت گمراهکننده است.
در نهایت، گزارش را برای تصمیمگیرنده ساده نگه دارید: یک جدول کوچک، دو یا سه یافته و یک اقدام بعدی با مسئول مشخص. گزارش طولانی که به تصمیم نمیرسد کمکی به افزایش سرنخ نمیکند.
چکلیست
- key eventهای اصلی (ارسال فرم، تماس) تعریف و تأیید شدهاند.
- رویدادهای مسیر کم و با نام ثابتاند.
- جمعآوری با Realtime و DebugView آزموده شده است.
- کیفیت سرنخ در دادهای جدا ثبت میشود.
- هیچ PII در URL، عنوان، پارامتر یا رویداد ارسال نمیشود.
- محدودیت attribution در گزارش ذکر شده است.
منابع و مراجع
- About events — Analytics Help (Google)، 2026-10-19.
- About key events — Analytics Help (Google)، 2026-10-19.
- Best practices to avoid sending Personally Identifiable Information (PII) — Analytics Help (Google)، 2026-10-19.
نویسنده
سا
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
برای انتخاب مسیر فنی پروژهتان کمک میخواهید؟
از مسئله و محدودیتهایتان بگویید؛ اگر بتوانیم همراهیتان کنیم، برای گفتوگو هماهنگ میکنیم.




