شما می توانید تمام تلاش خود را در طراحی یک استراتژی دقیق برای تجزیه و تحلیل محصول خود به کار ببندید، اما اگر ثبت و ردیابی رویدادهای شما دقیقاً همانطور که به آن نیاز دارید انجام نشده باشد، قطعا داده‌های شما بسیار کمتر از آنچه می‌خواهید سودمند می شوند. به این معنا که اگر آن داده ها برای تجزیه و تحلیل و تولید گزارش به برنامه‌ای داده شود، برنامه نتایج بیهوده‌ای را به عنوان خروجی تولید خواهد کرد.در این بخش 4 مشکل فنی مرتبط با داده‌های دارای خطای مربوط به ردیابی رویداد، شرح داده شده است و نحوه شناسایی آنها و اقداماتی که باید در مورد آنها انجام دهید نیز توضیح داده شده است.
1- گزارش پی در پی رویدادها
به عنوان یک مثال ساده در مورد گزارش پی در پی یک رویداد می‌توان گفت که این مشکل زمانی رخ می دهد که یک رویداد به صورت نامناسب دو یا چند بار پشت سر هم از یک دستگاه ردیابی شود. این مشکل حتی برای اکثر متخصصان تازه کار نیز به سادگی قابل تشخیص است.
یک برنامه پخش موسیقی را در نظر بگیرید که در آن رویدادی به نام “پخش موزیک” را ردیابی می‌کنید. این رویداد باید هر بار که کاربر آهنگی را پخش می کند فعال شود و نام آهنگ پخش شده را در رویداد فوق ثبت کند.
حال فرض کنید آنالیکا را باز کرده‌اید و مشاهده می‌کنید که “پخش موزیک” سه بار متوالی از یک دستگاه ردیابی شده است و یک عنوان آهنگ در هر سه رکورد ثبت شده است.
می‌توانیم فرض کنیم کاربر این آهنگ را سه بار پشت سر هم پخش کرده است اما این داده می تواند حاصل ایراد در کد ردیابی رویداد نیز باشد.
به عبارت دیگر، تصور کنید کاربر تنها یک بار آهنگ را پخش می کند اما کدی که رویداد “پخش موزیک” را ردیابی می‌کند، سه بار اجرا شده است در حالی که باید تنها یک بار اجرا می‌شد.
اگر با برنامه نویسی آشنا نیستید، احتمالا این موضوع کمی گیج کننده باشد، که اگر کاربر فقط یک بار آهنگ را پخش کرده است و یک بار آن را شنیده باشد چه نوع خطای فنی ای باعث می شود که بیش از یک بار این رویداد ردیابی شود؟!
دلایل فنی زیادی باعث بروز این اتفاق می‌شود که عمدتا مربوط به پیاده سازی ردیابی رویداد است. گاهی اوقات کدهای پیاده سازی شده برای ردیابی یک رویداد به ظاهر صحیح هستند، اما در واقع منجر به یک نتیجه کاملا غیرمنتظره می شود.بنابراین چگونه می توانید به عنوان یک فرد غیر متخصص تشخیص دهید که این داده ها واقعی هستند یا حاصل گزارش پی در پی یک رویداد؟
به عنوان مثال، اگر مشاهده می‌کنید که چندین آهنگ توسط چند کاربر بارها و بیشتر از یک حد قابل قبول، پشت سر هم پخش شده است یا رویدادها بلافاصله پشت سر هم مثلا در فاصله یک ثانیه یا کم تر ثبت شده اند به احتمال زیاد این گزارش حاصل یک اشکال در پیاده‌سازی است.
بنابراین، اگر با گزارش رویدادهای تکراری مواجه شدید که به نظر نادرست است، با تیم توسعه دهنده خود در مورد اجرای تست‌های خودکار که این موضوع را بررسی می‌کنند، گفت‌وگو کنید، یا حداقل یک بار روند ردیابی رویداد را مورد ارزیابی قرار دهید.
2- مشکل رویدادهای تکراری جدا از هم
متأسفانه، رویدادهای تکراری نادرست نه فقط به صورت تکرارهای پی در پی بلکه در حالت های مختلفی می‌توانند ظاهر شوند. بدین معنی که یک رویداد ممکن است در داشبورد شما تکراری ثبت شده باشد، اما به صورت متوالی و پشت سر هم نباشد. این حالت، باعث می‌شود تشخیص آن دشوارتر شود.
به عبارت دیگر، ردیابی تکراری یک رویداد در میان تعدادی از رویدادهای دیگر، که می‌تواند منجر به فرض صحیح بودن رویدادهای ثبت شده گردد.
با مثال برنامه پخش موسیقی ادامه دهیم، این بار مشاهده می‌کنید که رویداد “پخش موزیک” تنها یک بار ردیابی شده است، پس از آن پنج رویداد دیگر ردیابی شده و دوباره رویداد “پخش موزیک” ردیابی شده است. در این حالت شما با مخلوطی از رویدادهای تکراری مواجه هستید.
لازم به ذکر است که ذاتا هیچ مشکلی در این الگو وجود ندارد و برای اینکه مطمئن شوید مشکلی در ردیابی رویدادها وجود ندارد باید ارزیابی دقیقی انجام دهید.
بدین معنا که گاهی اوقات ردیابی چندین رویداد در فاصله چند میلی ثانیه از یکدیگر انجام می‌شود و ممکن است نشان دهنده یک سری از رویدادهای متمایز از هم باشد که به طور همزمان اتفاق افتاده‌اند. در نتیجه این رویدادها با هم ردیابی شده‌اند.
با این حال، همانطور که اشاره شد، منطقی نیست که رویدادهای “پخش موزیک” با فاصله چند میلی ثانیه از یکدیگر اتفاق بیفتد و این بدان معناست که اشتباهی رخ داده است.
چگونه از لحاظ فنی ممکن است این اتفاق رخ دهد؟
به گونه های مختلفی امکان وقوع این خطا وجود دارد. به عنوان مثال فرض کنید یک رویداد، به اشتباه، در دو مکان مختلف در برنامه شما، ردیابی شده است یا تصور کنید یک رویداد یک بار در سمت بک‌اند و یک بار هم در سمت فرانت‌اند برنامه شما ردیابی شده است.
این دو احتمال، از موارد ساده و پیش پا افتاده، به وجود آوردنده خطا هستند و برای افراد غیر کارشناس تشخیص ایرادات پیچیده‌تر به سختی امکان پذیر است. با این حال، اگر در رفتار کاربران نتایجی را مشاهده می‌کنید که در درستی آنها اطمینان ندارید، از یک فرد کارشناس برای بررسی و ارزیابی نتایج تجزیه و تحلیل محصول خود کمک بگیرید.
راه حل های قدرتمند، بازاریابی هوشمند
3- نادیده گرفتن رویدادها
در موارد اخیر در مورد اینکه چگونه رویدادها می‌توانند پی در پی و به طور نادرست ردیابی شوند، صحبت کردیم، اما لازم به ذکر است شرایطی وجود دارد که در آن ردیابی رویدادها به صورتی غیرآشکار، انجام نمی‌شود.
در این بخش نیز مثال برنامه پخش موسیقی را در نظر بگیرید، فرض کنید که شما وظیفه بررسی درستی ردیابی رویداد “پخش موزیک” را برعهده گرفته‌اید. شما آنالیکا را روی کامپیوتر خود باز کرده و آهنگ‌های مختلف را پخش می کنید. ملاحظه می‌کنید که یکی پس از دیگری، رویدادهای “پخش موزیک” با نام هر آهنگ همانطور که انتظار می رود در داشبورد، ظاهر می شود.
اما در این بین شما یک آهنگ خاص را پخش می‌کنید و منتظر هستید که رویداد مربوطه در آنالیکا نمایش داده شود اما هیچ اتفاقی نمی افتد و هیچ رویدادی ردیابی نمی شود.
سوال اینجاست که چرا این اتفاق رخ می دهد؟
آیا اشکال در برقراری شبکه اینترنت است؟ احتمالش وجود دارد، اما طراحی آنالیکا به نحوی است که به محض برقراری ارتباط اینترنت، ردیابی رویداد را انجام می دهد.
دوباره آهنگ را پخش می‌کنید، و این بار ملاحظه می‌کنید که رویداد ردیابی می‌شود. بنابراین شما فکر می کنید، “حتما این مشکل به طور اتفاقی و تنها برای یک بار بوده است” و به آزمایش ادامه می دهید، در حالی که این رخداد ناشی از وجود نقص در برنامه شما بوده است.
در این مثال، ممکن است توسعه دهنده برنامه، منطق خاصی را برای ردیابی رویداد، پیاده‌سازی کرده باشد که در آن مثلا باید یک آهنگ قبلاً در برنامه دانلود شده باشد تا ردیابی رویداد انجام شود و از آنجایی که شما در اولین باری که اقدام به پخش آهنگ مربوطه کرده‌اید، فایل آن تا به حال در برنامه دانلود نشده بود، حتی با وجود پخش آهنگ، رویداد ردیابی نشد. اما زمانی که برای بار دوم اقدام به پخش آهنگ کردید، فایل آن در برنامه بارگیری شده بود و رویداد همانطور که انتظار می رفت ثبت گردید.
به این ترتیب، تا زمانیکه منطق ردیابی رویداد اصلاح نشود، این مشکل برای هر آهنگی که در زمان پخش توسط کاربر، از قبل در دستگاه دانلود نشده است، اتفاق می‌افتد.
این دسته از مشکلات باید توسط تیم توسعه دهنده آزمایش شوند اما امکان اشتباه نیز هست، بنابراین اگر داده‌ها با انتظارات شما مطابقت نداشته باشند، احتمال نقص در توسعه برنامه وجود دارد.
4- عدم تطابق معنایی
تا اینجای کار، ایرادات فنی ای که در مورد آنها صحبت کردیم، مربوط به مواردی بودند که در آن رویدادهایی بیش از حد یا کمتر از مقدار واقعی، ردیابی شده اند.
اما گونه‌ای از ایرادات وجود دارد که تشخیص آنها به مراتب دشوارتر است و ناشی از روش تعریف رخداد یک رویداد است.
به این معنی که در وهله اول مشخص نیست که یک رویداد، مثلا رویداد “پخش موزیک” چه طور باید تعریف شود. آیا پخش یک آهنگ از ابتدا تا انتها، نشان دهنده رخ دادن رویداد است یا صرفاً شروع پخش یک آهنگ؟
اگر کاربر در حالی که یک آهنگ در حال پخش است به آهنگ دیگری پرش کند، یک رویداد جدید پخش آهنگ رخ داده است یا خیر؟
رویدادها باید با دقت تعریف شوند، در غیر این صورت ردیابی رویدادهای برنامه در معرض خطر داشتن مجموعه‌ای از ایرادات قرار خواهد گرفت. هنگامی که در تعریف یک رویداد دقت لازم را نداشته باشید، موجب تفسیر نادرست توسعه دهندگان برنامه جهت پیاده سازی صحیح یک رویداد و ردیابی آن خواهید شد.
حالت پیچیده‌تر این است که کارفرما و تیم توسعه دهنده در مورد معنای یک رویداد به توافق رسیده باشند، اما ظرافت‌های پیاده‌سازی رویداد باعث بروز مشکل شود.
به عنوان مثال، فرض کنید رویداد “پخش موزیک” را به این صورت تعریف کرده‌ایم که هر زمان یک آهنگ پخش شود بدون توجه به مدت زمانی که به آهنگ گوش داده شده است، رویداد مربوطه ردیابی شود. در این حالت باز هم گزینه‌های زیادی برای ردیابی این رویداد وجود دارد.
می‌توان در لحظه‌ای که کاربر روی دکمه پخش آهنگ کلید می‌کند، ردیابی را انجام داد. در این حالت این امکان وجود دارد که آهنگ مربوطه به علت قطعی اتصال به اینترنت دانلود نشود و آهنگ نیز پخش نشود، اما ردیابی انجام شده است و داده‌ها در اولین برقراری ارتباط با اینترنت ثبت خواهند شد.
همچنین، می‌توان رویداد را در همان لحظه‌ای که آهنگ شروع به پخش شدن می‌کند، ردیابی کرد. این حالت با تعریفی که از رویداد شده است تطابق بیشتری دارد زیرا پخش شدن آهنگ را تضمین می‌کند.
در هر حال افراد کارفرمای محصول باید با توسعه دهندگان در مورد چرایی پشت هر رویداد علاوه بر تعیین مرزهای آن بحث کنند. زیرا اگر علاقه مند باشیم که بدانیم آیا کاربر قصد دارد آهنگ را پخش کند یا خیر؟ روش اول روش مناسبی است اما اگر به دنبال این هستیم که آیا آهنگ واقعاً پخش شده است یا خیر، رویکرد دوم با هدف رویداد هماهنگ تر است.
جمع بندی
اگر در پیاده سازی ردیابی رویدادهای محصول دقت نظر لازم را به خرج ندهیم، به احتمال زیاد داده‌هایی که بدست می‌آوریم از صحت کافی برخوردار نخواهند بود. چرا که ردیابی صحیح رویدادها شدیدا به ویژگی‌های فنی، هم از منظر محصول و هم از منظر توسعه نیاز دارد. هرچه تیم محصول بیشتر از مشکلات فنی بالقوه آگاه باشد، احتمال اینکه ناهماهنگی ها از بین بروند بیشتر می شود و نتایج حاصل از تجزیه و تحلیل محصول، بینش دقیق‌تری به شما می‌بخشد.
ثبت دیدگاه