این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

ارتباط سرعت سایت و معیارهای کسب و کار

از تست A/B برای ارزیابی تاثیر سرعت سایت بر معیارهای کسب و کار خود استفاده کنید.

Bart Jarochowski

Martin Schierle

Dikla Cohen

در چند سال اخیر به خوبی ثابت شده است که عملکرد سرعت سایت بخش مهمی از تجربه کاربر است و بهبود آن به معیارهای مختلف تجاری مانند نرخ تبدیل و نرخ پرش کمک می کند. مقالات و مطالعات موردی متعددی برای حمایت از این موضوع منتشر شده است، از جمله نحوه عملکرد وب‌سایت Cloudflare بر نرخ تبدیل تأثیر می‌گذارد ، Deloitte's Milliseconds میلیون‌ها میلیون‌ها را می‌سازد ، و خرید برای سرعت در eBay.com .

با وجود اینکه موضوع سرعت واضح است، بسیاری از شرکت‌ها هنوز با اولویت‌بندی کارهایی که سرعت سایتشان را بهبود می‌بخشد، مبارزه می‌کنند، زیرا دقیقاً نمی‌دانند که چگونه بر کاربران و در نتیجه کسب‌وکارشان تأثیر می‌گذارد.

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

این مقاله راهنمایی‌های سطح بالایی را در مورد نحوه استفاده از تست A/B برای ارزیابی تأثیر سرعت سایت بر معیارهای تجاری ارائه می‌کند، بنابراین تصمیم‌گیری مؤثرتری را در مورد این موضوع ممکن می‌سازد.

مرحله 1: یک صفحه را برای تست A/B انتخاب کنید

هدف شما آزمایش این فرضیه است که سرعت صفحه با معیارهای کسب و کار شما مرتبط است. برای سادگی، در ابتدا می توانید خود را محدود به شناسایی یک صفحه برای تجزیه و تحلیل کنید. کار آینده می تواند به چندین صفحه از یک نوع برای تأیید یافته ها و سپس به سایر مناطق سایت گسترش یابد. برخی از پیشنهادات برای شروع از کجا در پایین این مرحله ارائه شده است. الزامات متعددی فرآیند انتخاب صفحه را هدایت می کند:

تست A/B فقط باید روی دستگاه های کاربران موبایل اجرا شود. در سطح جهانی، سایت های شریکی که ما به آنها کمک می کنیم، به طور متوسط بیش از 50٪ (و در حال رشد!) ترافیک خود را از طریق تلفن همراه می بینند، اما این میزان می تواند به طور قابل توجهی بر اساس منطقه و عمودی افزایش یابد. دستگاه‌های تلفن همراه به دلیل محدودیت‌های پردازش و حافظه و شبکه‌های پایدارتر نسبت به وب‌سایت‌های کندتر حساس‌تر هستند. همچنین، الگوهای استفاده در حال حرکت به این معنی است که انتظارات برای سرعت بالاتر است.
صفحه ای که برای آزمایش انتخاب می کنید باید بخش مهمی از قیف تبدیل شما باشد. هر سایتی هدف متفاوتی دارد، بنابراین هر سایتی معیارهای موفقیت متفاوتی را دنبال می کند. این معیارها معمولاً مربوط به سفر کاربر است که با استفاده از یک قیف تجزیه و تحلیل می شود. به عنوان مثال، کاربران در یک وب سایت تجارت الکترونیک باید از طریق صفحه اصلی، صفحات دسته بندی، صفحات محصول و صفحه پرداخت برای تکمیل خرید حرکت کنند. اگر در حال بهینه سازی برای تبدیل هستید، یکی از آن صفحات کاندیدای خوبی خواهد بود.
صفحه باید یک هدف منحصر به فرد داشته باشد. مگر اینکه سایت شما مأموریت بسیار خاصی داشته باشد، معمولاً بهتر است از استفاده از صفحه اصلی برای آزمایش خودداری کنید. صفحات اصلی بسیاری از سایت های تجاری پورتال هایی برای طیف گسترده ای از عملکردها هستند که تجزیه و تحلیل شما را پر سر و صدا می کند. به عنوان مثال، اگر برای بازدید از صفحه در هر جلسه در یک سایت خبری بهینه‌سازی می‌کنید، شاید بهتر باشد بخش‌های غیرتجاری سایت را حذف کنید و بر بخش‌ها و مقاله‌های کسب درآمد تمرکز کنید.
صفحه انتخاب شده باید ترافیک کافی داشته باشد تا قبل از گرفتن نتیجه آماری قابل توجهی نیازی به صبر طولانی نداشته باشید.
صفحه انتخاب شده باید نسبتا کند باشد. در واقع، هر چه کندتر، بهتر است. این نه تنها به این معنی است که احتمالاً زمان آسان تری برای بهبود صفحه خواهید داشت، بلکه به این معنی است که داده ها باید بسیار واضح تر باشند. می توانید یک اسکن سریع از طریق گزارش سرعت Google Analytics یا گزارش Core Web Vitals کنسول جستجوی خود انجام دهید تا ببینید کدام یک از صفحات شما کندتر هستند.
صفحه باید نسبتاً پایدار باشد. تا زمانی که آزمایش کامل نشده است، صفحات را (هر چیزی که بر معیارهای کسب و کار تأثیر می گذارد) به روز نکنید. هرچه عوامل خارجی کمتری در نظر گرفته شود، تجزیه و تحلیل تمیزتر خواهد بود.

با استفاده از موارد فوق به عنوان راهنما، باید کمی واضح تر مشخص شود که چه صفحاتی کاندیدای خوبی برای آزمون شما هستند. صفحات فرود تبلیغاتی نیز انتخاب خوبی هستند، زیرا به احتمال زیاد معیارهای تجاری داخلی، تست A/B و تجزیه و تحلیل در اختیار شماست. اگر هنوز مطمئن نیستید، در اینجا چند ایده برای هر عمودی وجود دارد:

وب سایت های محتوا: بخش ها، مقالات
ویترین ها: صفحات دسته بندی، صفحات محصول
پخش کننده رسانه: صفحات کشف/جستجوی ویدئو، صفحه پخش ویدئو
خدمات و کشف (مسافرت، اتومبیل های کرایه ای، ثبت نام خدمات و غیره): صفحه ورود به فرم اولیه

مرحله 2: اندازه گیری عملکرد

دو روش کلی برای اندازه گیری معیارها وجود دارد: در آزمایشگاه و در میدان . ما شخصاً تشخیص داده‌ایم که معیارهای اندازه‌گیری در این زمینه (همچنین به عنوان نظارت بر کاربر واقعی (RUM) شناخته می‌شود) مفیدتر است زیرا تجربه کاربران واقعی را منعکس می‌کند. نمونه‌هایی از کتابخانه‌ها و سرویس‌هایی که می‌توانند به شما در گزارش داده‌های RUM کمک کنند عبارتند از Perfume ، Firebase Performance Monitoring ، و رویدادهای Google Analytics .

معیارهای زیادی برای انتخاب وجود دارد زیرا هدف آنها ثبت جنبه های مختلف تجربه کاربر است. به یاد داشته باشید که هدف شما این است که در نهایت تعیین کنید که آیا یک همبستگی مستقیم بین معیارهای سرعت و کسب و کار شما وجود دارد، بنابراین ممکن است مفید باشد که چند معیار سرعت را دنبال کنید تا مشخص کنید کدام یک قوی‌ترین همبستگی را با موفقیت کسب و کار شما دارد. به طور کلی توصیه می کنیم با Core Web Vitals شروع کنید. کتابخانه web-vitals.js می تواند به شما کمک کند برخی از Core Web Vitals را در این زمینه اندازه گیری کنید، اگرچه توجه داشته باشید که پشتیبانی از مرورگر 100٪ نیست . فراتر از Core Web Vitals، سایر Web Vitals نیز ارزش بررسی دارند. همچنین می‌توانید معیارهای سفارشی مانند «زمان برای اولین کلیک آگهی» را تعریف کنید.

مرحله 3: انواع عملکرد سرعت را ایجاد کنید

در این مرحله تغییراتی را برای ایجاد یک نسخه سریعتر از صفحه برای آزمایش در برابر نسخه فعلی اعمال خواهید کرد.

چند نکته را باید در نظر داشت:

از ایجاد هرگونه تغییر در UI یا UX خودداری کنید. گذشته از اینکه یک صفحه سریعتر از دیگری است، تغییرات باید برای کاربران نامرئی باشد.
اندازه گیری نیز یکی از جنبه های کلیدی این مرحله است. هنگام توسعه، ابزارهای آزمایش آزمایشگاهی مانند Lighthouse باید برای نشان دادن تأثیر تغییرات شما بر عملکرد استفاده شود. به خاطر داشته باشید که تغییرات در یک معیار اغلب می تواند بر دیگری تأثیر بگذارد. هنگامی که صفحات زنده شدند، برای ارزیابی دقیق تر به RUM بچسبید.

ایجاد انواع عملکرد را می توان به روش های مختلفی انجام داد. برای هدف از آزمون، شما می خواهید این کار را به ساده ترین شکل ممکن انجام دهید. در زیر چند گزینه وجود دارد.

یک صفحه سریعتر ایجاد کنید

از ابزاری مانند Squoosh برای بهینه سازی دستی تصاویر در صفحه آزمایشی خود استفاده کنید
از پوشش کد DevTools برای حذف دستی جاوا اسکریپت یا CSS استفاده نشده فقط برای آن یک صفحه استفاده کنید .
اسکریپت های شخص ثالث را به طور موثر بارگیری کنید
از ابزاری مانند Critical برای شکستن و درون‌سازی CSS حیاتی استفاده کنید
کدهای جاوا اسکریپت غیر مهم را که بر تجربه کاربر تأثیر نمی‌گذارد و می‌توانید بدون آن برای هدف آزمایش انجام دهید، حذف کنید (به عنوان مثال، برخی از کتابخانه‌های شخص ثالث)
اجرای بارگیری تنبل در سطح مرورگر که توسط همه مرورگرها پشتیبانی نمی‌شود، اما همچنان ممکن است در صورت پشتیبانی عملکرد را به میزان قابل توجهی بهبود بخشد.
برچسب های تجزیه و تحلیل غیر بحرانی را حذف کنید یا آنها را به صورت ناهمزمان بارگذاری کنید

بهینه‌سازی‌های اضافی را می‌توان در زمان‌های بارگذاری سریع و چک لیست عملکرد Frontend پیدا کرد. همچنین می‌توانید از PageSpeed Insights برای اجرای Lighthouse استفاده کنید، که فرصت‌هایی را برای بهبود عملکرد شناسایی می‌کند.

سرعت صفحه را کم کنید

این ممکن است ساده‌ترین راه برای ایجاد انواع مختلف باشد و می‌توان با افزودن یک اسکریپت ساده، کاهش سرعت پاسخ سرور، بارگیری تصاویر بزرگ‌تر و غیره به آن دست یافت. Financial Times هنگام آزمایش تأثیر عملکرد بر معیارهای کسب‌وکارشان، این گزینه را انتخاب کرد: به FT.com سریع‌تر مراجعه کنید.

افزایش سرعت بارگذاری صفحه

برای مواردی که صفحه آزمایشی (مثلاً یک صفحه جزئیات محصول) عمدتاً از یک صفحه دیگر (مثلاً صفحه اصلی) پیوند داده شده است، واکشی یا اجرای اولیه صفحه محصول مستقیماً از صفحه اصلی برای گروه آزمایشی، بارگذاری بعدی صفحه را سرعت می‌بخشد. توجه داشته باشید که در این حالت تقسیم تست A/B (مرحله 4) در صفحه اصلی انجام می شود. علاوه بر این، همه اینها ممکن است صفحه اول را کاهش دهد، بنابراین مطمئن شوید که آن را اندازه بگیرید و هنگام تجزیه و تحلیل نتایج آزمون آن را در نظر بگیرید (مرحله 5).

مرحله 4: یک تست A/B ایجاد کنید

هنگامی که دو نسخه از یک صفحه دارید که یکی از آنها سریعتر از دیگری است، گام بعدی تقسیم ترافیک برای اندازه گیری تأثیر است. به طور کلی تکنیک ها و ابزارهای زیادی برای انجام تست های A/B وجود دارد، اما توجه داشته باشید که همه روش ها برای اندازه گیری تاثیر عملکرد سرعت مناسب نیستند.

اگر از ابزار تست A/B مانند Optimizely یا Optimize استفاده می‌کنید، اکیداً توصیه می‌کنیم که به جای تست سمت سرویس گیرنده، یک تست سمت سرور راه‌اندازی کنید، زیرا تست A/B سمت مشتری اغلب با پنهان کردن محتوای صفحه تا زمانی که آزمایش بارگیری شود کار می‌کند، که به این معنی است که خود تست A/B معیارهایی را که می‌خواهید اندازه‌گیری کنید منحرف می‌کند. اگر فقط می‌توانید آزمایش سمت مشتری انجام دهید، آزمایش را در صفحه دیگری راه‌اندازی کنید و خروجی‌های پیوند را به صفحه آزمایشی خود تغییر دهید تا ترافیک را تقسیم کنید. به این ترتیب خود صفحه آزمایشی توسط تست سمت مشتری به پایین کشیده نمی شود.

مثال

نمونه ای از تغییرات عملکرد تست AB در صفحه جزئیات محصول (PDP) از طریق تست سمت سرور:

درخواست به باطن می رود، که کاربران را در دو نسخه مختلف صفحه توزیع می کند. در حالی که این به طور کلی یک راه‌اندازی خوب است، اغلب برای راه‌اندازی تقسیم سمت سرور به منابع فناوری اطلاعات نیاز دارد.

در اینجا نمونه ای از تنظیمات تست سمت سرویس گیرنده است که از صفحه قبلی (صفحه اصلی در نمودار زیر) برای اجرای آزمایشی جاوا اسکریپت استفاده می کند:

جاوا اسکریپت آزمایشی پیوند خروجی را دستکاری می کند تا به دو گروه آزمایشی کاربران پیوندهایی به دو نسخه PDP مورد نظر بدهد. راه‌اندازی و نگهداری از طریق ابزارهای رایج تست A/B مانند Optimizely یا Optimize آسان است و بر تست عملکرد تأثیری ندارد زیرا جاوا اسکریپت آزمایشی در صفحه دیگری اجرا می‌شود.

از طرف دیگر، می توانید دو صفحه را انتخاب کنید که رفتار و عملکرد بسیار مشابهی دارند (مثلاً برای دو محصول بسیار مشابه). تغییرات خود را در یکی از آنها اعمال کنید و سپس تفاوت معیارها را در طول زمان مقایسه کنید. این بدان معناست که شما تست A/B مناسبی را انجام نمی دهید، اما هنوز هم می تواند کاملاً روشنگر باشد.

در صورتی که صفحه آزمایشی شما به عنوان صفحه فرود برای کمپین های تبلیغاتی استفاده می شود، استفاده از ابزارهای تست A/B داخلی شبکه تبلیغاتی شما، مانند تست تقسیم تبلیغات Facebook یا Google Ads Drafts & Experiments می تواند مفید باشد. اگر این یک گزینه نیست، می توانید از دو کمپین با تنظیمات یکسان استفاده کنید و صفحات فرود مختلف را به عنوان هدف تعیین کنید.

مرحله 5: آزمون A/B را تجزیه و تحلیل کنید

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

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

پلتفرم هایی مانند Optimizely یا Optimize نیز راه های آسانی را برای تفسیر نتایج و تعیین میزان تأثیر سرعت بر صفحات شما ارائه می دهند.

اگر از Google Analytics یا ابزاری مشابه استفاده می کنید، باید خودتان گزارش را جمع آوری کنید. خوشبختانه، Google Analytics ساخت گزارش های سفارشی را بسیار آسان می کند، بنابراین از اینجا باید شروع کنید. اگر داده‌های سرعت را با استفاده از یک بعد سفارشی به Google Analytics ارسال کرده‌اید، راهنمای گزارش‌دهی را بررسی کنید تا نحوه تنظیم آن‌ها و گنجاندن آنها در گزارش‌های سفارشی خود را بیاموزید. مطمئن شوید که گزارش شما تاریخ آزمایش را پوشش می دهد و برای نمایش هر دو نوع پیکربندی شده است. در این گزارش چه باید کرد؟

در درجه اول، شما باید معیارهای کسب و کار را که بیشتر به آن اهمیت می دهید شامل کنید: تبدیل، بازدید از صفحه، تبلیغات مشاهده شده، نرخ تبدیل، معیارهای تجارت الکترونیک، نرخ کلیک و غیره.
علاوه بر این، سایر معیارهای استاندارد صفحه که مورد خوبی برای بهبود سرعت سایت هستند عبارتند از نرخ پرش، میانگین مدت جلسه و درصد خروج.

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

Looker Studio (سابق Data Studio) یا سایر ابزارهای تجسم داده، ادغام منابع داده های مختلف از جمله Google Analytics را آسان می کند. این امر انجام تجزیه و تحلیل را آسان می کند و همچنین داشبوردهایی ایجاد می کند که با بسیاری از سهامداران درگیر در اجرای یک وب سایت مدرن برای خرید بیشتر قابل اشتراک گذاری است. به عنوان مثال، گاردین یک سیستم هشدار خودکار ایجاد کرد که به تیم تحریریه هشدار می‌داد که محتوای اخیراً منتشر شده از اندازه صفحه یا آستانه سرعت آنها عبور کند و احتمالاً منجر به نارضایتی کاربران شود.

مرحله 6: نتیجه گیری کنید و در مورد مراحل بعدی تصمیم بگیرید

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

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

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

هشدارها

ممکن است دلایل مختلفی برای پیدا نکردن همبستگی قابل توجهی بین معیارهای سرعت سایت و معیارهای تجاری وجود داشته باشد:

صفحه انتخاب شده تأثیر کافی بر معیارهای کسب و کار مورد بررسی شما ندارد. به عنوان مثال، اگر صفحه تسویه حساب بسیار غیر دوستانه یا کند باشد، ممکن است صفحه محصول سریعتر تأثیر زیادی بر نرخ تبدیل نداشته باشد. به معیارهای مرتبط تری مانند نرخ پرش، نرخ افزودن به سبد خرید یا هر معیار دیگری که مستقیماً به صفحه ای که در حال آزمایش آن هستید متصل است، توجه کنید.
تفاوت سرعت بین دو نسخه به اندازه کافی قابل توجه نیست. این باید با توجه به معیارهای RUM که اندازه گیری می کنید ارزیابی شود.
مکانیسم تست A/B ایراد دارد. ممکن است ترافیک به درستی توزیع نشده باشد یا تجزیه و تحلیل به درستی گزارش نشده باشد. به منظور رد این موضوع، آزمایش A/A را در نظر بگیرید که در آن نسخه یک صفحه را با استفاده از مکانیسم آزمایش یکسان آزمایش می‌کنید و مطمئن شوید که هنگام انجام این کار تفاوتی در نتایج وجود ندارد.
سرعت سایت واقعاً بر معیارهای کسب و کار شما تأثیر نمی گذارد. این نادر است اما در مواردی که بازار هدف شما حساسیت کمتری به سرعت دارد (مثلاً سایت بیشتر از طریق دستگاه‌های قدرتمند در یک شبکه قوی قابل دسترسی است) یا تقاضای کاربر بسیار زیاد و انتخاب محدود است (مثلاً یک سرویس فروش بلیط که منحصراً بلیط‌های نمایش‌های پرتقاضا را می‌فروشد) رخ می‌دهد. توجه داشته باشید که این بدان معنا نیست که یک سایت سریعتر تجربه کاربر را بهبود نمی بخشد و در نتیجه بر شهرت برند تأثیر می گذارد .

نتیجه گیری

در حالی که راه اندازی بهینه سازی سرعت در کل سایت وسوسه انگیز است، اما معمولاً در دراز مدت مفیدتر است که ابتدا درک کنید که داشتن یک وب سایت سریعتر برای کاربران و شرکت شما چه معنایی دارد. این تفاوت بین گفتن "ما FCP را 1.5 ثانیه بهبود دادیم" و "ما FCP را 1.5 ثانیه بهبود دادیم و نرخ تبدیل ما را 5٪ بهبود دادیم". این به شما امکان می دهد کارهای بیشتر را اولویت بندی کنید، از سهامداران مختلف خرید کنید و عملکرد سرعت سایت را به تلاشی در سطح شرکت تبدیل کنید .

از تست A/B برای ارزیابی تاثیر سرعت سایت بر معیارهای کسب و کار خود استفاده کنید.

Bart Jarochowski

Martin Schierle

Dikla Cohen

مرحله 1: یک صفحه را برای تست A/B انتخاب کنید

تست A/B فقط باید روی دستگاه های کاربران موبایل اجرا شود. در سطح جهانی، سایت های شریکی که ما به آنها کمک می کنیم، به طور متوسط بیش از 50٪ (و در حال رشد!) ترافیک خود را از طریق تلفن همراه می بینند، اما این میزان می تواند به طور قابل توجهی بر اساس منطقه و عمودی افزایش یابد. دستگاه‌های تلفن همراه به دلیل محدودیت‌های پردازش و حافظه و شبکه‌های پایدارتر نسبت به وب‌سایت‌های کندتر حساس‌تر هستند. همچنین، الگوهای استفاده در حال حرکت به این معنی است که انتظارات برای سرعت بالاتر است.
صفحه ای که برای آزمایش انتخاب می کنید باید بخش مهمی از قیف تبدیل شما باشد. هر سایتی هدف متفاوتی دارد، بنابراین هر سایتی معیارهای موفقیت متفاوتی را دنبال می کند. این معیارها معمولاً مربوط به سفر کاربر است که با استفاده از یک قیف تجزیه و تحلیل می شود. به عنوان مثال، کاربران در یک وب سایت تجارت الکترونیک باید از طریق صفحه اصلی، صفحات دسته بندی، صفحات محصول و صفحه پرداخت برای تکمیل خرید حرکت کنند. اگر در حال بهینه سازی برای تبدیل هستید، یکی از آن صفحات کاندیدای خوبی خواهد بود.
صفحه باید یک هدف منحصر به فرد داشته باشد. مگر اینکه سایت شما مأموریت بسیار خاصی داشته باشد، معمولاً بهتر است از استفاده از صفحه اصلی برای آزمایش خودداری کنید. صفحات اصلی بسیاری از سایت های تجاری پورتال هایی برای طیف گسترده ای از عملکردها هستند که تجزیه و تحلیل شما را پر سر و صدا می کند. به عنوان مثال، اگر برای بازدید از صفحه در هر جلسه در یک سایت خبری بهینه‌سازی می‌کنید، شاید بهتر باشد بخش‌های غیرتجاری سایت را حذف کنید و بر بخش‌ها و مقاله‌های کسب درآمد تمرکز کنید.
صفحه انتخاب شده باید ترافیک کافی داشته باشد تا قبل از گرفتن نتیجه آماری قابل توجهی نیازی به صبر طولانی نداشته باشید.
صفحه انتخاب شده باید نسبتا کند باشد. در واقع، هر چه کندتر، بهتر است. این نه تنها به این معنی است که احتمالاً زمان آسان تری برای بهبود صفحه خواهید داشت، بلکه به این معنی است که داده ها باید بسیار واضح تر باشند. می توانید یک اسکن سریع از طریق گزارش سرعت Google Analytics یا گزارش Core Web Vitals کنسول جستجوی خود انجام دهید تا ببینید کدام یک از صفحات شما کندتر هستند.
صفحه باید نسبتاً پایدار باشد. تا زمانی که آزمایش کامل نشده است، صفحات را (هر چیزی که بر معیارهای کسب و کار تأثیر می گذارد) به روز نکنید. هرچه عوامل خارجی کمتری در نظر گرفته شود، تجزیه و تحلیل تمیزتر خواهد بود.

وب سایت های محتوا: بخش ها، مقالات
ویترین ها: صفحات دسته بندی، صفحات محصول
پخش کننده رسانه: صفحات کشف/جستجوی ویدئو، صفحه پخش ویدئو
خدمات و کشف (مسافرت، اتومبیل های کرایه ای، ثبت نام خدمات و غیره): صفحه ورود به فرم اولیه

مرحله 2: اندازه گیری عملکرد

مرحله 3: انواع عملکرد سرعت را ایجاد کنید

در این مرحله تغییراتی را برای ایجاد یک نسخه سریعتر از صفحه برای آزمایش در برابر نسخه فعلی اعمال خواهید کرد.

چند نکته را باید در نظر داشت:

از ایجاد هرگونه تغییر در UI یا UX خودداری کنید. گذشته از اینکه یک صفحه سریعتر از دیگری است، تغییرات باید برای کاربران نامرئی باشد.
اندازه گیری نیز یکی از جنبه های کلیدی این مرحله است. هنگام توسعه، ابزارهای آزمایش آزمایشگاهی مانند Lighthouse باید برای نشان دادن تأثیر تغییرات شما بر عملکرد استفاده شود. به خاطر داشته باشید که تغییرات در یک معیار اغلب می تواند بر دیگری تأثیر بگذارد. هنگامی که صفحات زنده شدند، برای ارزیابی دقیق تر به RUM بچسبید.

یک صفحه سریعتر ایجاد کنید

از ابزاری مانند Squoosh برای بهینه سازی دستی تصاویر در صفحه آزمایشی خود استفاده کنید
از پوشش کد DevTools برای حذف دستی جاوا اسکریپت یا CSS استفاده نشده فقط برای آن یک صفحه استفاده کنید .
اسکریپت های شخص ثالث را به طور موثر بارگیری کنید
از ابزاری مانند Critical برای شکستن و درون‌سازی CSS حیاتی استفاده کنید
کدهای جاوا اسکریپت غیر مهم را که بر تجربه کاربر تأثیر نمی‌گذارد و می‌توانید بدون آن برای هدف آزمایش انجام دهید، حذف کنید (به عنوان مثال، برخی از کتابخانه‌های شخص ثالث)
اجرای بارگیری تنبل در سطح مرورگر که توسط همه مرورگرها پشتیبانی نمی‌شود، اما همچنان ممکن است در صورت پشتیبانی عملکرد را به میزان قابل توجهی بهبود بخشد.
برچسب های تجزیه و تحلیل غیر بحرانی را حذف کنید یا آنها را به صورت ناهمزمان بارگذاری کنید

سرعت صفحه را کم کنید

افزایش سرعت بارگذاری صفحه

مرحله 4: یک تست A/B ایجاد کنید

مثال

نمونه ای از تغییرات عملکرد تست AB در صفحه جزئیات محصول (PDP) از طریق تست سمت سرور:

مرحله 5: آزمون A/B را تجزیه و تحلیل کنید

در درجه اول، شما باید معیارهای کسب و کار را که بیشتر به آن اهمیت می دهید شامل کنید: تبدیل، بازدید از صفحه، تبلیغات مشاهده شده، نرخ تبدیل، معیارهای تجارت الکترونیک، نرخ کلیک و غیره.
علاوه بر این، سایر معیارهای استاندارد صفحه که مورد خوبی برای بهبود سرعت سایت هستند عبارتند از نرخ پرش، میانگین مدت جلسه و درصد خروج.

مرحله 6: نتیجه گیری کنید و در مورد مراحل بعدی تصمیم بگیرید

هشدارها

صفحه انتخاب شده تأثیر کافی بر معیارهای کسب و کار مورد بررسی شما ندارد. به عنوان مثال، اگر صفحه تسویه حساب بسیار غیر دوستانه یا کند باشد، ممکن است صفحه محصول سریعتر تأثیر زیادی بر نرخ تبدیل نداشته باشد. به معیارهای مرتبط تری مانند نرخ پرش، نرخ افزودن به سبد خرید یا هر معیار دیگری که مستقیماً به صفحه ای که در حال آزمایش آن هستید متصل است، توجه کنید.
تفاوت سرعت بین دو نسخه به اندازه کافی قابل توجه نیست. این باید با توجه به معیارهای RUM که اندازه گیری می کنید ارزیابی شود.
مکانیسم تست A/B ایراد دارد. ممکن است ترافیک به درستی توزیع نشده باشد یا تجزیه و تحلیل به درستی گزارش نشده باشد. به منظور رد این موضوع، آزمایش A/A را در نظر بگیرید که در آن نسخه یک صفحه را با استفاده از مکانیسم آزمایش یکسان آزمایش می‌کنید و مطمئن شوید که هنگام انجام این کار تفاوتی در نتایج وجود ندارد.
سرعت سایت واقعاً بر معیارهای کسب و کار شما تأثیر نمی گذارد. این نادر است اما در مواردی که بازار هدف شما حساسیت کمتری به سرعت دارد (مثلاً سایت بیشتر از طریق دستگاه‌های قدرتمند در یک شبکه قوی قابل دسترسی است) یا تقاضای کاربر بسیار زیاد و انتخاب محدود است (مثلاً یک سرویس فروش بلیط که منحصراً بلیط‌های نمایش‌های پرتقاضا را می‌فروشد) رخ می‌دهد. توجه داشته باشید که این بدان معنا نیست که یک سایت سریعتر تجربه کاربر را بهبود نمی بخشد و در نتیجه بر شهرت برند تأثیر می گذارد .

نتیجه گیری

اگرچه بهینه سازی سرعت در کل سایت وسوسه انگیز است ، اما معمولاً در دراز مدت مفیدتر است تا ابتدا بفهمید که برای کاربران و شرکت شما به معنای داشتن یک وب سایت سریعتر چیست. این تفاوت بین گفتن "ما FCP را 1.5 ثانیه بهبود بخشیدیم" و "ما FCP را 1.5 ثانیه بهبود دادیم و این باعث بهبود نرخ تبدیل ما 5 ٪ شد." این امر به شما امکان می دهد تا کار بیشتری را در اولویت قرار دهید ، از ذینفعان مختلف خرید کنید و عملکرد سرعت سایت را به یک تلاش در سطح شرکت تبدیل کنید .

آزمایش A/B را برای ارزیابی تأثیر سرعت سایت در معیارهای تجاری خود ارزیابی کنید.

Bart Jarochowski

Martin Schierle

Dikla Cohen

طی چند سال گذشته به خوبی مشخص شده است که عملکرد سرعت سایت بخش مهمی از تجربه کاربر است و بهبود آن به نفع معیارهای مختلف تجاری مانند نرخ تبدیل و نرخ گزاف گویی است. مقالات متعدد و مطالعات موردی برای تهیه نسخه پشتیبان از این مورد منتشر شده است ، از جمله نحوه عملکرد وب سایت CloudFlare بر نرخ تبدیل بر نرخ تبدیل ، میلی ثانیه Deloitte ، میلیون ها نفر را می سازد و خرید سرعت در eBay.com را برای نامگذاری چند مورد.

حتی اگر مورد سرعت مشخص باشد ، بسیاری از شرکت ها هنوز هم با اولویت بندی کار تلاش می کنند که سرعت سایت آنها را بهبود می بخشد زیرا آنها دقیقاً نمی دانند چگونه بر کاربران آنها تأثیر می گذارد و در نتیجه تجارت آنها .

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

در این مقاله راهنمایی های سطح بالایی در مورد چگونگی استفاده از آزمایش A/B برای ارزیابی تأثیر سرعت سایت بر معیارهای تجاری ارائه می شود ، بنابراین امکان تصمیم گیری مؤثرتر در مورد موضوع را فراهم می کند.

مرحله 1: یک صفحه را به آزمون A/B انتخاب کنید

هدف شما آزمایش این فرضیه است که سرعت صفحه مربوط به معیارهای تجاری شما است. به خاطر سادگی ، در ابتدا می توانید خود را در شناسایی یک صفحه واحد برای تجزیه و تحلیل محدود کنید. کار آینده می تواند برای تأیید یافته ها و سپس به سایر مناطق سایت به چندین صفحه از همان نوع گسترش یابد. برخی از پیشنهادات برای شروع کار در پایین این مرحله ارائه شده است. چندین مورد نیاز فرآیند انتخاب صفحه را هدایت می کند:

آزمایش A/B فقط باید روی دستگاه های کاربران تلفن همراه اجرا شود. در سطح جهان ، سایت های شریک ما به ما کمک می کنیم تا به طور متوسط بیش از 50 ٪ (و در حال رشد!) از ترافیک آنها از تلفن همراه باشد ، اما این می تواند بر اساس منطقه و عمودی افزایش یابد. دستگاه های تلفن همراه به دلیل محدودیت های پردازش و حافظه و شبکه های با ثبات کمتری نسبت به وب سایت های کندتر حساس تر هستند. همچنین ، الگوهای استفاده از روی حرکت به معنای انتظارات برای سرعت بیشتر است.
صفحه ای که برای آزمایش انتخاب می کنید باید بخش مهمی از قیف تبدیل شما باشد. هر سایتی از هدف متفاوتی برخوردار است ، بنابراین هر سایت معیارهای مختلف موفقیت را دنبال می کند. این معیارها معمولاً مربوط به سفر کاربر است که با استفاده از قیف مورد تجزیه و تحلیل قرار می گیرد. به عنوان مثال ، کاربران در یک وب سایت تجارت الکترونیکی برای تکمیل خرید باید از طریق صفحه اصلی ، صفحات دسته بندی ، صفحات محصول و یک صفحه پرداخت حرکت کنند. اگر برای تبدیل ها بهینه سازی می کنید ، یکی از این صفحات کاندیدای خوبی خواهد بود.
این صفحه باید یک هدف مفرد داشته باشد. مگر اینکه سایت شما مأموریت بسیار خاصی داشته باشد ، معمولاً بهتر است از استفاده از صفحه اصلی برای تست خود خودداری کنید. بسیاری از صفحه اصلی سایت های تجاری پورتال هایی با طیف گسترده ای از قابلیت ها هستند که تجزیه و تحلیل شما را پر سر و صدا می کند. به عنوان مثال ، اگر در هر جلسه در یک سایت خبری برای صفحه نمایش بهینه می کنید ، بهتر است بخش های غیر تجاری سایت را حذف کرده و روی بخش ها و مقالات درآمدزایی تمرکز کنید.
صفحه انتخاب شده باید به اندازه کافی ترافیک پیدا کند تا نیازی به صبر کردن نتیجه آماری قابل توجهی نباشد.
صفحه انتخاب شده باید نسبتاً کند باشد. در واقع ، کندتر بهتر است. این نه تنها به این معنی است که شما به احتمال زیاد در بهبود صفحه زمان آسانتری خواهید داشت ، بلکه به این معنی است که داده ها باید بسیار واضح تر باشند. شما می توانید یک اسکن سریع را از طریق گزارش Google Analytics Speed یا گزارش Core Core Core Vitals خود انجام دهید تا ببینید کدام یک از صفحات شما کمترین است.
صفحه باید نسبتاً پایدار باشد. صفحات را به روز نکنید (هر چیزی که بر معیارهای تجاری تأثیر بگذارد) تا زمانی که آزمون کامل شود. کمتر عوامل خارجی در نظر گرفته شده است ، پاک کننده تجزیه و تحلیل خواهد بود.

استفاده از موارد فوق به عنوان راهنما باید کمی واضح تر باشد که کدام صفحات نامزدهای خوبی برای آزمون شما هستند. صفحات فرود تبلیغات نیز انتخاب خوبی است ، زیرا احتمالاً شما معیارهای تجاری داخلی ، آزمایش A/B و تجزیه و تحلیل را در اختیار دارید. در صورت عدم اطمینان ، در اینجا برخی از ایده ها در هر عمودی وجود دارد:

وب سایت های محتوا: بخش ها ، مقالات
فروشگاه ها: صفحات دسته بندی ، صفحات محصول
پخش کننده های رسانه ای: کشف ویدیویی/صفحات جستجو ، صفحه پخش ویدیویی
خدمات و کشف (سفر ، اتومبیل های اجاره ای ، ثبت نام خدمات و غیره): صفحه اولیه ورود به سیستم

مرحله 2: اندازه گیری عملکرد

دو روش کلی برای اندازه گیری معیارها وجود دارد: در آزمایشگاه و این زمینه . ما شخصاً معیارهای اندازه گیری را در این زمینه (که به عنوان نظارت کاربر واقعی (RUM) نیز شناخته می شود) پیدا کرده ایم زیرا این نشان دهنده تجربه کاربران واقعی است. نمونه هایی از کتابخانه ها و خدماتی که می تواند به شما در گزارش داده های رم کمک کند شامل عطر ، نظارت بر عملکرد Firebase و رویدادهای Google Analytics است.

معیارهای زیادی برای انتخاب وجود دارد زیرا هدف آنها ضبط جنبه های مختلف تجربه کاربر است. به یاد داشته باشید که هدف شما این است که در نهایت مشخص کنید که آیا بین سرعت و معیارهای تجاری شما ارتباط مستقیمی وجود دارد ، بنابراین ممکن است پیگیری چند معیار سرعت مفید باشد تا مشخص شود کدام یک با موفقیت در کسب و کار شما قوی ترین ارتباط دارد. به طور کلی توصیه می کنیم با ویتام های اصلی وب شروع کنید. کتابخانه Web-Vitals.JS می تواند به شما در اندازه گیری برخی از ویتارهای اصلی وب در این زمینه کمک کند ، اگرچه توجه داشته باشید که پشتیبانی مرورگر 100 ٪ نیست . فراتر از ویتای اصلی وب ، سایر ویتامین های وب نیز ارزش بررسی دارند. همچنین می توانید معیارهای سفارشی مانند "Time to First Ad Click" را تعریف کنید.

مرحله 3: انواع عملکرد سرعت را ایجاد کنید

در این مرحله تغییراتی را برای ایجاد نسخه سریعتر از صفحه برای آزمایش در برابر نسخه فعلی اجرا خواهید کرد.

چند نکته را باید در نظر داشت:

از ایجاد هرگونه تغییر در UI یا UX خودداری کنید. گذشته از اینکه یک صفحه سریعتر از صفحه دیگر باشد ، تغییرات باید برای کاربران نامرئی باشد.
اندازه گیری همچنین جنبه اصلی این مرحله است. در حالی که در حال توسعه است ، باید از ابزارهای آزمایش آزمایشگاه مانند Lighthouse استفاده شود تا تأثیر تغییرات شما بر عملکرد را نشان دهد. به خاطر داشته باشید که تغییر در یک متریک اغلب می تواند بر دیگری تأثیر بگذارد. پس از زنده بودن صفحات ، برای ارزیابی دقیق تر به رم بچسبید.

ایجاد انواع عملکرد می تواند به روش های مختلفی انجام شود. به منظور آزمایش ، شما می خواهید این کار را تا حد امکان انجام دهید. در زیر چند گزینه وجود دارد.

یک صفحه سریعتر ایجاد کنید

برای بهینه سازی دستی تصاویر در صفحه تست خود از ابزاری مانند Squoosh استفاده کنید
از پوشش کد DevTools برای از بین بردن دستی JavaScript یا CSS استفاده کنید فقط برای یک صفحه
اسکریپت های شخص ثالث را به طور موثر بارگیری کنید
از ابزاری مانند بحرانی برای شکستن و درون خطی CSS استفاده کنید
کد JavaScript غیر بحرانی را که بر تجربه کاربر تأثیر نمی گذارد حذف کنید و بدون هدف آزمون می توانید انجام دهید (به عنوان مثال ، برخی از کتابخانه های شخص ثالث)
اجرای بارگذاری تنبل در سطح مرورگر که توسط همه مرورگرها پشتیبانی نمی شود اما هنوز هم ممکن است عملکرد را به میزان قابل توجهی در جایی که پشتیبانی می شود بهبود بخشد
برچسب های تجزیه و تحلیل غیر بحرانی را حذف کنید یا آنها را به صورت غیر همزمان بارگیری کنید

بهینه سازی های اضافی که باید در نظر بگیرید می توانید در زمان بارگذاری سریع و لیست عملکرد عملکرد جلو مشاهده کنید. همچنین می توانید از Pagespeed Insights برای اجرای Lighthouse استفاده کنید ، که فرصت های بهبود عملکرد را مشخص می کند.

صفحه را کند کنید

این ممکن است ساده ترین راه برای ایجاد انواع باشد و با افزودن یک اسکریپت ساده ، کاهش سرعت پاسخ سرور ، بارگیری تصاویر بزرگتر و غیره می توان به دست آورد.

سرعت بار صفحه

برای مواردی که صفحه آزمون (بیایید بگوییم یک صفحه جزئیات محصول) بیشتر از صفحه دیگری مرتبط است (بیایید بگوییم صفحه اصلی) ، تنظیم یا پیش نویس صفحه محصول را مستقیماً از صفحه اصلی برای گروه آزمایشی برای بار بعدی صفحه سرعت می بخشد. توجه داشته باشید که در این حالت تقسیم تست A/B (مرحله 4) در صفحه اصلی انجام می شود. علاوه بر این ، همه اینها ممکن است صفحه اول را کند کند ، بنابراین حتماً آن را اندازه گیری کرده و هنگام تجزیه و تحلیل نتایج آزمون (مرحله 5) آن را مورد توجه قرار دهید.

مرحله 4: تست A/B ایجاد کنید

هنگامی که شما دو نسخه از همان صفحه دارید که یکی از آن سریعتر از دیگری است ، مرحله بعدی تقسیم ترافیک برای اندازه گیری ضربه است. به طور کلی تکنیک ها و ابزارهای زیادی برای انجام تست های A/B وجود دارد ، اما توجه داشته باشید که همه روش ها برای اندازه گیری تأثیر عملکرد سرعت مناسب نیستند.

اگر از یک ابزار تست A/B مانند Optimizely استفاده می کنید یا بهینه سازی می کنیم ، ما اکیداً توصیه می کنیم به جای آزمایش سمت مشتری ، تست سمت سرور را تنظیم کنید ، زیرا آزمایش A/B مشتری اغلب با مخفی کردن محتوای صفحه تا زمان بارگیری آزمایش کار می کند ، این بدان معنی است که آزمایش A/B به خودی خود معیارهای شما را اندازه گیری می کند. اگر فقط می توانید آزمایش سمت مشتری را انجام دهید ، آزمایش را در صفحه دیگری تنظیم کنید و پیوندها را به صفحه آزمایش خود تغییر دهید تا ترافیک را تقسیم کنید. به این ترتیب صفحه آزمون به خودی خود توسط آزمون سمت مشتری کشیده نمی شود.

مثال

نمونه ای از تغییرات عملکرد AB در صفحه جزئیات محصول خاص (PDP) از طریق آزمایش سمت سرور:

این درخواست به پس زمینه می رود که کاربران را به دو نسخه مختلف صفحه توزیع می کند. در حالی که این به طور کلی یک تنظیم خوب است ، اما اغلب به منابع IT برای تنظیم تقسیم سمت سرور نیاز دارد.

در اینجا نمونه ای از تنظیمات آزمایش سمت مشتری ، با استفاده از صفحه قبلی (صفحه اصلی در نمودار زیر) برای اجرای JavaScript آزمایش شده است:

Testing JavaScript لینک خروجی را دستکاری می کند تا به دو گروه آزمایشی از کاربران پیوند به دو نسخه PDP مورد نظر ارائه دهد. این آسان برای تنظیم و نگهداری از طریق ابزارهای تست A/B مشترک مانند Optimizely یا Optimize آسان است و در آزمون عملکرد تأثیر نمی گذارد زیرا Testing JavaScript در صفحه دیگری اجرا می شود.

از طرف دیگر ، می توانید دو صفحه را انتخاب کنید که رفتار می کنند و بسیار مشابه عمل می کنند (برای مثال ، برای دو محصول بسیار مشابه). تغییرات خود را در یکی از آنها اعمال کنید و سپس تفاوت در معیارها را در طول زمان مقایسه کنید. این بدان معناست که شما در حال انجام آزمایش مناسب A/B نیستید ، اما هنوز هم می تواند کاملاً بصیرت باشد.

در صورت استفاده از صفحه تست شما به عنوان صفحه فرود برای تبلیغات تبلیغاتی ، می توان از استفاده از ابزارهای تست داخلی A/B شبکه تبلیغاتی خود استفاده کرد ، مانند تست های Split Facebook Ads Split یا Google Ads Draft و آزمایشات . اگر این گزینه نیست ، می توانید از دو کمپین با همان تنظیم استفاده کنید و صفحات فرود مختلف را به عنوان اهداف تعیین کنید.

مرحله 5: آزمون A/B را تجزیه و تحلیل کنید

بعد از اینکه آزمایش خود را به اندازه کافی طولانی انجام داده اید و داده های کافی برای احساس اطمینان نسبت به نتایج داشته باشید ، وقت آن است که همه را کنار هم قرار داده و تجزیه و تحلیل را اجرا کنید. چگونه این کار را انجام می دهید واقعاً بستگی به نحوه اجرای این آزمون دارد ، بنابراین بیایید گزینه ها را طی کنیم.

اگر تست شما در صفحات فرود AD با استفاده از ابزارهای فوق الذکر اجرا شد ، تجزیه و تحلیل باید به همان اندازه خواندن نتیجه ساده باشد. اگر از پیش نویس ها و آزمایش های Google استفاده می کنید ، با استفاده از کارت امتیازی به مقایسه توجه کنید.

سیستم عامل هایی مانند Optimizely یا Optimize همچنین روشهای آسان برای تفسیر نتایج و تعیین میزان سرعت تأثیر در صفحات شما ارائه می دهند.

اگر از Google Analytics یا یک ابزار مشابه استفاده می کنید ، باید خودتان گزارش را جمع کنید. خوشبختانه ، Google Analytics تهیه گزارش های سفارشی را بسیار آسان می کند ، بنابراین باید از آنجا شروع کنید. اگر داده های سرعت را با استفاده از ابعاد سفارشی به Google Analytics ارسال کرده اید ، برای یادگیری نحوه تنظیم آنها و در گزارش های سفارشی خود ، از راهنمای گزارشگری دیدن کنید. اطمینان حاصل کنید که گزارش شما تاریخ آزمایش را پوشش می دهد و برای نمایش هر دو نوع پیکربندی شده است. چه چیزی باید در این گزارش انجام شود؟

در درجه اول ، شما باید معیارهای تجاری را که بیشتر به آنها اهمیت می دهید ، درج کنید: تبدیل ، صفحه نمایش ، تبلیغات مشاهده شده ، نرخ تبدیل ، معیارهای تجارت الکترونیکی ، نرخ کلیک و غیره.
علاوه بر این ، سایر معیارهای استاندارد صفحه که همچنین مورد خوبی برای بهبود سرعت سایت ایجاد می کنند ، نرخ گزاف گویی ، میانگین مدت زمان جلسه و درصد خروج هستند.

همچنین ممکن است شما نیاز به فیلتر کردن موبایل داشته باشید و حتماً رباتها و سایر ترافیک غیر کاربر را حذف کنید . تجزیه و تحلیل پیشرفته تر همچنین می تواند توسط منطقه ، شبکه ها ، دستگاه ها ، منبع ترافیک و پروفایل ها و انواع کاربر مانند کاربران جدید در مقابل بازدید کنندگان مکرر فیلتر شود. هر گروه از کاربران ممکن است نسبت به سرعت کندتر حساس باشند و شناسایی این موارد نیز بسیار مفید است.

Looker Studio (سابق داده استودیو) یا سایر ابزارهای تجسم داده ها ، ادغام منابع مختلف داده از جمله Google Analytics را آسان می کند. این امر انجام تجزیه و تحلیل را آسان می کند ، و همچنین ایجاد داشبورد هایی که با بسیاری از ذینفعان درگیر در اجرای یک وب سایت مدرن برای خرید بیشتر قابل اشتراک هستند. به عنوان مثال ، گاردین یک سیستم هشدار خودکار ایجاد کرد که به تیم تحریریه هشدار داد وقتی که اخیراً مطالب منتشر شده است ، از اندازه صفحه یا آستانه سرعت خود عبور کرده و احتمالاً منجر به کاربران ناراضی خواهد شد.

مرحله ششم: نتیجه گیری کنید و در مورد مراحل بعدی تصمیم بگیرید

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

اگر می توانید به وضوح بین بهبود عملکرد و بهبود معیارهای تجاری مشاهده کنید ، نتایج را خلاصه کرده و آنها را در سراسر شرکت گزارش دهید. اکنون که می توانید در مورد عملکرد سرعت در "زبان تجاری" صحبت کنید ، احتمالاً توجه ذینفعان مختلف را به خود جلب کرده و عملکرد سرعت سایت را در رادار همه قرار می دهید. قدم بعدی تعیین بودجه های عملکرد بر اساس نتایج و برنامه ریزی برای کار برای تأمین بودجه ها است. از آنجا که می دانید ارزشی که چنین کارهایی ارائه می دهد ، می توانید بر این اساس اولویت بندی کنید.

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

هشدارها

ممکن است دلایل مختلفی برای عدم پیدا کردن همبستگی معنی داری بین معیارهای سرعت سایت و معیارهای تجاری وجود داشته باشد:

صفحه انتخاب شده تأثیر کافی در معیارهای تجاری که شما بررسی می کنید ندارد. به عنوان مثال ، اگر صفحه پرداخت بسیار دوستانه یا کند باشد ، ممکن است یک صفحه محصول سریعتر تأثیر زیادی در نرخ تبدیل نداشته باشد. در نظر بگیرید که به معیارهای مرتبط تر مانند نرخ گزاف گویی ، نرخ افزودن به سبد خرید یا هر متریک دیگری که مستقیماً به صفحه ای که آزمایش می کنید متصل شود.
تفاوت سرعت بین دو نسخه به اندازه کافی معنی دار نیست. این باید با توجه به معیارهای RUM که اندازه گیری می کنید ارزیابی شود.
با مکانیسم آزمایش A/B یک خطای وجود دارد. ممکن است ترافیک به درستی توزیع نشود یا تجزیه و تحلیل به درستی گزارش نشده باشد. به منظور رد این مسئله ، یک آزمایش A/A را در نظر بگیرید که در آن نسخه مشابه یک صفحه را با استفاده از همان مکانیسم آزمایش آزمایش می کنید و اطمینان حاصل می کنید که در انجام این کار هیچ تفاوتی در نتایج وجود ندارد.
سرعت سایت واقعاً در معیارهای تجاری شما تأثیر نمی گذارد. این نادر است اما می تواند در مواردی رخ دهد که بازار هدف شما نسبت به سرعت حساسیت کمتری داشته باشد (به عنوان مثال سایت بیشتر از دستگاه های قدرتمند در یک شبکه قوی قابل دسترسی است) یا تقاضای کاربر بسیار زیاد است و انتخاب محدود است (به عنوان مثال یک سرویس بلیط که منحصراً بلیط هایی را برای نمایش های پر تقاضا می فروشد). توجه داشته باشید که این بدان معنا نیست که یک سایت سریعتر تجربه کاربر را بهبود نمی بخشد و در نتیجه بر اعتبار برند تأثیر می گذارد .