فرض کنیم نام کسب‌وکارمان در پاسخ یک ابزار هوش مصنوعی دیده می‌شود. می‌توانیم از این مشاهده خوشحال باشیم، اما هنوز چند پرسش باز است: اطلاعات درست است؟ مخاطب مرتبط آن را می‌بیند؟ راهی برای بررسی بیشتر دارد؟ و در نهایت، چه کاری می‌تواند انجام دهد؟ پاسخ این پرسش‌ها تعیین می‌کند مشاهده نام برند چقدر برای پروژه ما ارزش دارد.
مقاله ماری هینز در سرچ انجین ژورنال، با نقد تمرکز صرف بر GEO، توجه را به نتیجه کسب‌وکار و فرصت انجام کار با کمک عامل‌ها می‌برد. منظور از عامل، سامانه‌ای است که می‌تواند در چارچوب درخواست کاربر، بخشی از یک کار را پیگیری یا اجرا کند. برای استفاده از این بحث، لازم نیست حکم بدهیم همه فعالیت‌های GEO بی‌فایده‌اند. بهتر است داده‌ها را درست بخوانیم و از میان پیشنهادهای مختلف، کاری را انتخاب کنیم که به نیاز مشتری و امکانات واقعی ما مربوط است.
در نخستین تصویر، گوگل ارگانیک با مجموع ابزارهای زبانی مقایسه شده است. داده‌ها به نمونه ۱۰۰ سایت مربوط‌اند و تصویر برای نمایش اختلاف مقیاس از نقطه‌ها استفاده می‌کند. این مقایسه نشان می‌دهد در همان داده‌ها، تعداد نشست‌های گوگل بسیار بیشتر بوده است. اما به‌تنهایی نمی‌گوید وضعیت همه سایت‌ها، همه صنعت‌ها یا مخاطبان فارسی‌زبان همین است.
عبارت «سهم ترافیک» را هم با دقت به کار ببریم. سهم یک گروه از مجموع دو گروه، با نسبت آن گروه به گوگل یکسان نیست. در این تصویر، نسبت کوچک بودن دسته ابزارهای زبانی روشن است، اما نباید عددهای گرد‌شده را به سهم همه کانال‌های سایت تبدیل کنیم. کانال‌های دیگری مانند ورود مستقیم یا شبکه‌های اجتماعی موضوع این مقایسه نیستند.
تصویر دوم به ۵۵ سایت دارای ثبت رویداد کلیدی مربوط است. در آن، حدود ۹۶.۴۵ درصد از مجموع رویدادهای دو گروه مقایسه‌شده، به گوگل ارگانیک مربوط است و حدود ۳.۵۵ درصد به ابزارهای زبانی. عدد ۳.۶۸ درصد که در بخش دیگری دیده می‌شود، نسبت رویدادهای ابزارهای زبانی به گوگل است. این دو درصد، مخرج متفاوت دارند.
همچنین نرخ تبدیل بالاتر ورودی ابزارهای زبانی با حجم کمتر رویدادهای آن‌ها قابل جمع است. نرخ، نسبت یک نتیجه به ورودی تعریف‌شده است؛ حجم، تعداد نتیجه را بیان می‌کند. برای همین، تنها با اعلام نرخ بالاتر نمی‌توان گفت یک کانال فروش بیشتری ساخته است. باید شمارش، تعریف نتیجه و در صورت نیاز، درآمد مرتبط را هم ببینیم.
تصویر سوم روند ارجاع‌های ChatGPT را از ژانویه ۲۰۲۴ تا سپتامبر ۲۰۲۶ نشان می‌دهد. در بخش ابتدایی، رشد دیده می‌شود و در بخش بعد، مقدارها بالا و پایین می‌شوند. همین شکل یادآوری می‌کند که امتداد دادن رشد یک دوره به آینده، فرضی نیازمند بررسی است. روند مشاهده‌شده را باید از پیش‌بینی جدا نگه داریم.
نکته دیگر، تفاوت بازه‌هاست. نمودار روند ماهانه را نباید به‌عنوان جز دیگری از همان مقایسه ۱۲ماهه معرفی کنیم. همچنین نشست‌های ارجاعی، تعداد استفاده‌کنندگان از ChatGPT نیستند. کاربر ممکن است از یک ابزار استفاده کند و وارد سایت نشود. این تصویر، همان ارجاع‌های ثبت‌شده را نشان می‌دهد و برای پاسخ به پرسش‌های دیگر، داده دیگری لازم است.
وقتی بازدید ۱۰۰ سایت و رویداد ۵۵ سایت را داریم، نباید تعداد رویدادهای گروه دوم را بر بازدید کل گروه اول تقسیم کنیم و نرخ تازه‌ای بسازیم. صورت و مخرج باید به جامعه، بازه و تعریف سازگار مربوط باشند. کنار هم بودن دو نمودار در یک مقاله، این سازگاری را خودبه‌خود ایجاد نمی‌کند.
برای بررسی داده سایت خودمان نیز همین قاعده برقرار است. اگر یک گزارش فقط بخشی از کشورها یا دستگاه‌ها را دارد، مقایسه آن با گزارش کلی نیاز به توضیح دارد. اگر تعریف رویداد در میانه دوره عوض شده، تغییر عدد می‌تواند از روش اندازه‌گیری هم آمده باشد. پیش از تحلیل روند، باید بدانیم چه چیزی در هر دوره ثبت شده است.
سایت‌های بزرگ‌تر می‌توانند در مجموع داده وزن بیشتری داشته باشند. بنابراین نتیجه تجمیعی لزوما رفتار یک سایت معمولی در نمونه را نشان نمی‌دهد. همچنین نوع محصول، طول مسیر خرید و مخاطب کسب‌وکارها ممکن است متفاوت باشد. از یک نسبت کلی نمی‌توان بدون بررسی، بودجه مناسب پروژه دیگری را استخراج کرد.
کاربرد درست این داده‌ها، ساخت پرسش است: آیا در سایت ما هم اختلاف حجم وجود دارد؟ کیفیت درخواست‌ها چگونه است؟ کدام مسیر ارزش بیشتری می‌سازد؟ پاسخ باید با داده همان کسب‌وکار ساخته شود. اگر هنوز اندازه‌گیری قابل اتکایی نداریم، نتیجه منطقی، راه‌اندازی و بررسی اندازه‌گیری است؛ نه انتخاب کانال برنده از روی نمودار شخص دیگری.
در GA4 می‌توان رویدادی را که برای کسب‌وکار اهمیت دارد به‌عنوان Key event مشخص کرد. اما نام‌گذاری، صحت اجرا را تضمین نمی‌کند. ممکن است رویداد برای کلیک روی دکمه ثبت شود، درحالی‌که هدف واقعی ما ارسال موفق درخواست است. باید تعریف تجاری و نقطه فنی ثبت رویداد با هم تطبیق داشته باشند.
برای آزمایش، مسیر را مانند یک کاربر طی کنیم. اگر فرم خطا دارد، آیا رویداد موفقیت باز هم ثبت می‌شود؟ اگر صفحه دوباره باز شود، آیا شمارش تغییر می‌کند؟ اگر درخواست به سامانه داخلی نرسد، کدام داده این شکست را نشان می‌دهد؟ پاسخ این پرسش‌ها کمک می‌کند قبل از نسبت دادن موفقیت به یک کانال، معنای عدد را بررسی کنیم.
اگر ورودی یک کانال بیشتر تبدیل می‌شود، هنوز نمی‌دانیم خود کانال علت تفاوت بوده است. شاید کاربران آن با نیاز روشن‌تری آمده باشند، شاید صفحه‌های متفاوتی دیده باشند یا ترکیب محصول‌ها فرق داشته باشد. برای تحلیل، باید این احتمال‌ها را در نظر بگیریم و از یک مقایسه مشاهده‌ای، نتیجه قطعی درباره اثر تغییر بودجه نسازیم.
پیشنهاد عملی این است که صفحه‌های ورود و نوع نتیجه را جدا بررسی کنیم. درخواست خدمات را با خرید محصول در یک عدد مبهم جمع نکنیم. اگر داده کافی نیست، دامنه نتیجه را کوچک نگه داریم. می‌توان گفت «در این بخش از داده، این الگو دیده شده»؛ لازم نیست از همان ابتدا درباره همه مشتریان حکم کلی بدهیم.
ارزش بررسی پاسخ‌های هوش مصنوعی همیشه فقط کلیک نیست. ممکن است بخواهیم بدانیم نام محصول درست نوشته می‌شود یا اطلاعات خدمات با واقعیت سازگار است. چنین بررسی‌ای می‌تواند خروجی مفیدی داشته باشد، به شرط آنکه هدفش روشن باشد. اصلاح معرفی نادرست را باید با همان معیار ارزیابی کرد؛ نسبت دادن مستقیم آن به فروش نیازمند شاهد بیشتری است.
برای این کار، نمونه پرسش‌ها، پاسخ‌ها و شرایط بررسی را ثبت کنیم. سپس مشخص کنیم کدام اطلاعات در اختیار خودمان است و چه اصلاحی می‌توان انجام داد. اگر داده منبع یا صفحه محصول غلط است، همان را اصلاح کنیم. حضور در یک پاسخ متغیر را نباید به وعده کنترل کامل معرفی برند در همه ابزارها تبدیل کرد.
راهنمای گوگل می‌گوید اصول SEO برای AI Overviews و AI Mode نیز مرتبط‌اند و فایل یا نشانه‌گذاری ویژه تازه‌ای برای حضور در این قابلیت‌ها لازم نیست. این توضیح، تضمین نمایش نیست؛ یادآوری می‌کند که نباید هر ادعای فنی تازه را شرط عمومی حضور در پاسخ‌های گوگل فرض کرد.
در بازبینی سایت، ابتدا ببینیم کاربر به اطلاعات اصلی می‌رسد یا نه. ویژگی محصول، محدودیت خدمت و قدم بعدی باید روشن باشد. پیوندها باید به ادامه کار کمک کنند و اطلاعات متناقض اصلاح شوند. این کارها را با نیاز واقعی صفحه انجام دهیم، نه با افزودن عبارت‌های تکراری درباره هوش مصنوعی به متن.
در یک فروشگاه، عامل یا کاربر برای انتخاب به داده درست نیاز دارد: کدام مدل، چه گزینه‌هایی، چه موجودی و چه شرایطی برای تحویل وجود دارد؟ اگر پاسخ در صفحه، منبع محصول و مرحله خرید متفاوت باشد، مسیر تصمیم آسیب می‌بیند. ابتدا باید منبع معتبر این اطلاعات و شیوه به‌روزرسانی آن مشخص شود.
راهنمای Merchant Center بر دقت داده و سازگاری آن با سایت تاکید دارد. این کار می‌تواند شامل بررسی قیمت، موجودی، گونه‌های محصول و شرایط لازم باشد. اما داشتن داده بهتر را نباید تضمین انتخاب شدن توسط عامل یا افزایش رتبه معرفی کنیم. معیار نخست، کاهش تناقض و درست بودن اطلاعاتی است که کسب‌وکار ارایه می‌کند.
فناوری UCP به تعامل تجاری میان کسب‌وکار، پلتفرم و عامل مربوط است. پروفایل معرفی قابلیت‌ها در اسناد گوگل، در مسیر /.well-known/ucp تعریف شده است. این پروفایل عمومی، توضیح قابلیت‌هاست؛ وجود آن به معنی عمومی بودن دسترسی به همه اقدام‌های تجاری یا انجام خودکار خرید نیست.
اگر چنین اتصالی برای کسب‌وکار قابل استفاده باشد، باید محدوده اجرا روشن شود. کدام قابلیت پشتیبانی می‌شود؟ داده از کجا می‌آید؟ نتیجه عملیات چطور بررسی می‌شود؟ چه کسی تغییرهای نسخه و خطاهای اتصال را پیگیری می‌کند؟ این‌ها پرسش‌های محصول و توسعه‌اند و به همکاری فراتر از نگارش متن نیاز دارند.
در توضیح Chrome، فناوری WebMCP برای معرفی ساختاریافته ابزارهای صفحه به عامل‌ها مطرح شده و همچنان استانداردی پیشنهادی است. برای یک بررسی اولیه، بهتر است از قابلیتی محدود شروع کنیم؛ مثلا یافتن زمان‌های موجود، بدون اینکه آزمایش از ابتدا تمام مسیر رزرو و پرداخت را دربر بگیرد.
در طراحی آزمایش، ورودی معتبر، خروجی قابل قبول و رفتار هنگام خطا را بنویسیم. اگر زمانی وجود ندارد، ابزار باید همین وضعیت را روشن برگرداند. اگر داده کافی نیست، نباید موفقیت ساختگی نشان دهد. سود آزمایش در شناخت قابلیت و محدودیت است؛ یک اجرای موفق نمایشی، همه وضعیت‌های واقعی را پوشش نمی‌دهد.
در سناریوی عامل‌محور، بهتر است میان پیدا کردن گزینه و اقدام نهایی تفاوت بگذاریم. کاربر ممکن است فقط درخواست مقایسه داده باشد. نتیجه طراحی باید با همان درخواست سازگار باشد. پیش از ساخت قابلیت، مشخص کنیم کدام مرحله اطلاعات می‌دهد و کدام مرحله تعهدی مانند ثبت سفارش یا رزرو ایجاد می‌کند.
این تفکیک به تجربه عادی سایت هم کمک می‌کند. کاربر باید بداند چه چیزی انتخاب شده، چه چیزی قطعی شده و چطور می‌تواند نتیجه را بررسی کند. اگر مسیر فعلی این وضعیت‌ها را روشن نمی‌کند، ابتدا همان تجربه را بهتر کنیم. افزودن عامل، جای توضیح روشن وضعیت و راه رسیدگی به خطا را نمی‌گیرد.
ممکن است مخاطب ابتدا نام کسب‌وکار را در جای دیگری ببیند و بعد با روش دیگری وارد سایت شود. گزارش ورودی به‌تنهایی شرح کامل این مسیر نیست. در مقابل، نمی‌توان هر ورود مستقیم یا هر جست‌وجوی نام برند را هم به هوش مصنوعی نسبت داد. هر دو نتیجه‌گیری به داده‌ای بیشتر از نام منبع آخرین ورود نیاز دارند.
برای شناخت بهتر مسیر، می‌توان در گفت‌وگو با مشتری یا فرم اختیاری پس از خرید، از شیوه آشنایی پرسید. پاسخ‌ها را همراه محدودیتشان بخوانیم؛ حافظه مشتری و تعریف کانال‌ها همیشه دقیق نیست. این اطلاعات می‌توانند پرسش‌های تازه بسازند، اما نباید به‌عنوان اندازه‌گیری کامل اثر همه برخوردهای قبلی معرفی شوند.
در گزارش، بهتر است داده ثبت‌شده، پاسخ خود مشتری و برداشت تحلیلی جدا بمانند. اگر این سه را در یک عدد جمع کنیم، خواننده نمی‌داند کدام بخش مشاهده شده و کدام بخش استنباط است. شفافیت درباره نوع شاهد، از یک برآورد دقیق‌نما مفیدتر است و مسیر بهبود اندازه‌گیری را هم روشن‌تر می‌کند.
همه سایت‌ها فروشگاه نیستند. یک رسانه می‌تواند بررسی کند مخاطب برای دسترسی به آرشیو یا دنبال کردن یک موضوع چه مشکلی دارد. یک کسب‌وکار خدماتی هم می‌تواند مسیر انتخاب خدمت و ارسال اطلاعات لازم را بازبینی کند. این‌ها پیشنهاد برای شناخت کار مخاطب‌اند؛ لازم نیست هرکدام از ابتدا به پروژه اتصال عامل تبدیل شوند.
ابتدا ببینیم کدام بخش با اطلاعات بهتر یا ابزار ساده‌تر حل می‌شود. شاید توضیح روشن محدوده خدمت، از ساخت یک قابلیت تازه مفیدتر باشد. شاید یک جست‌وجوی داخلی قابل استفاده، نیاز فعلی رسانه را پاسخ دهد. انتخاب باید از مشاهده مشکل بیاید تا ابزار برای کاری ساخته شود که کسی واقعا می‌خواهد انجام دهد.
اگر بعدتر استفاده عامل‌ها مطرح شد، همان کار مشخص مبنای طراحی قرار می‌گیرد. در این حالت می‌توان بررسی کرد چه ورودی و خروجی ساختاریافته‌ای لازم است و آیا زیرساخت موجود پاسخ می‌دهد یا نه. این مسیر، فرصت آینده را به یک قابلیت واقعی متصل می‌کند و از ساخت امکاناتی که تنها نام تازه‌ای دارند جلوگیری خواهد کرد.
برای شروع، می‌توان یک برگه کوتاه ساخت: کار مشتری چیست، مشکل کجاست، چه تغییری پیشنهاد می‌شود و نتیجه را چگونه می‌سنجیم؟ سپس فرد پیگیر، دامنه اجرا و شرط بازبینی را مشخص کنیم. لازم نیست نخستین آزمایش، پروژه‌ای بزرگ با چند فناوری باشد. باید پرسشی را پاسخ دهد که نتیجه آن تصمیم ما را تغییر می‌دهد.
پس از اجرا، فقط موفقیت‌ها را ثبت نکنیم. خطا، هزینه پشتیبانی و مواردی که کاربر به کمک نیاز داشته هم بخشی از نتیجه‌اند. اگر اثر روشن نیست، نتیجه را نامشخص بنویسیم. اگر کاربردی پیدا نشده، توقف همان آزمایش می‌تواند تصمیم درستی باشد. هدف، ساخت مسیری مفید برای مشتری است؛ فناوری زمانی ارزش دارد که در این مسیر کاری مشخص انجام دهد.
تهیه شده توسط تیم تخصصی SEO سید احسان خسروی (مدیر، متخصص و مشاور استراتژیک SEO)
