સાઇટના રૂટ લેઆઉટ (root layout) માં રહેલા એક શેર કરેલા ફંક્શનને કારણે A/B-ટેસ્ટ એક્સપોઝર કાઉન્ટર (exposure counter), પેજ-વ્યુ કાઉન્ટરમાં બદલાઈ ગયું, જેનાથી સેમ્પલ સાઈઝ વધી ગઈ અને કન્વર્ઝન રેટ્સ (conversion rates) અર્થહીન બની ગયા. હોમપેજનું 50/50 સ્પ્લિટ ધરાવતા આ ટેસ્ટમાં, એક વેરિઅન્ટ (variant) માટે 178 હિટ્સ અને બીજા માટે 57 હિટ્સ નોંધાયા—જે અપેક્ષિત સમાન વિભાજનથી ઘણું દૂર હતું.
ભૂલ રેન્ડમાઇઝર (randomizer) થી કેવી રીતે છૂટી ગઈ
ડેવલપરે સૌ પ્રથમ મુલાકાતીઓને વેરિઅન્ટમાં ફાળવતા રેન્ડમાઇઝરની ચકાસણી કરી. તેણે મિડલવેર (middleware) વાંચ્યું, કૂકી લોજિક (cookie logic) ની તપાસ કરી અને એક સ્ક્રિપ્ટ ચલાવી જેણે એસાઇનમેન્ટ ફંક્શનને 10,000 વખત કોલ કર્યું; તેનાથી પરફેક્ટ 50/50 સ્પ્લિટ મળ્યું. રેન્ડમાઇઝર પોતે બરાબર કામ કરતું હતું; સમસ્યા એ હતી કે એક્સપોઝર કેવી રીતે રેકોર્ડ કરવામાં આવતું હતું.
એક જ ફંક્શન બે કામ કરતું હતું:
- વેરિઅન્ટ સેટ કરવો (Set the variant) – મુલાકાતીનો અનુભવ સુસંગત રાખવા માટે દરેક પેજ લોડ પર ચાલે છે.
- એક્સપોઝર ઇવેન્ટ રેકોર્ડ કરવી (Record the exposure event) – વેરિઅન્ટ પહેલીવાર દેખાય તે ક્ષણે, દરેક મુલાકાતી માટે માત્ર એક જ વાર ફાયર થવી જોઈએ.
આ ફંક્શન રૂટ લેઆઉટમાં હતું, જે દરેક નેવિગેશન પર રેન્ડર થતું ઘટક (component) છે. એક્સપોઝર-રેકોર્ડિંગ કોડ દરેક વખતે લેઆઉટ રેન્ડર થાય ત્યારે એક્ઝિક્યુટ થતો હોવાથી, દરેક પેજ વ્યુ એક નવા એક્સપોઝર તરીકે ગણવામાં આવતો હતો. હોમપેજના બંને વેરિઅન્ટ્સ થોડા અલગ લેઆઉટ ટ્રીઝ (layout trees) નો ઉપયોગ કરતા હતા, તેથી તેમના પેજ-વ્યુ રેટ્સ અલગ પડતા હતા, જેના કારણે રેન્ડમાઇઝર બગડી ગયું હોય તેવો ભ્રમ પેદા થયો.
ખોટી ગણતરી કેમ મહત્વની હતી
કન્વર્ઝન આંકડા—ક્લિક-થ્રુ (click-throughs), સાઇન-અપ્સ, ખરીદી—સાચી રીતે લોગ થયા હતા. પરંતુ છેદ (denominator - એક્સપોઝરની સંખ્યા) ખોટો હતો. ગણતરી કરેલા કન્વર્ઝન રેટ્સ વાસ્તવિકતા કરતા ઘણા ઓછા દેખાતા હતા, અને તે રેટ્સ પર આધારિત કોઈપણ નિર્ણયો અવિશ્વસનીય હતા.
આ વિસંગતતા સામે આવતા પહેલા ટેસ્ટ બે અઠવાડિયા સુધી ચાલ્યો હતો, જેના કારણે ટીમને આખો ડેટા સેટ ફેંકી દેવો પડ્યો.
ઉકેલ
ઉકેલ સીધો હતો: જવાબદારીઓને અલગ-અલગ ફંક્શન્સમાં વહેંચી દેવી. એક્સપોઝર-રેકોર્ડિંગ કોડ હવે તપાસે છે કે મુલાકાતીની ગણતરી થઈ ગઈ છે કે નહીં, અને દરેક યુઝર માટે માત્ર એક જ વાર ફાયર થાય છે. વેરિઅન્ટ-સેટિંગ કોડ તેની જગ્યાએ જ રહે છે અને દરેક નેવિગેશન પર ચાલવાનું ચાલુ રાખે છે.
પ્રયોગો ચલાવનાર કોઈપણ વ્યક્તિ માટે ત્રણ મહત્વની બાબતો
- સ્ટેટ-સેટિંગ (state-setting) ને વન-ઓફ ઇવેન્ટ્સ (one-off events) થી અલગ કરો. જે ફંક્શન વેરિઅન્ટ ફાળવે છે અને એક્સપોઝર લોગ કરે છે તે બંને વચ્ચે સંઘર્ષ થશે કારણ કે પહેલું વારંવાર થાય છે જ્યારે બીજું થવું જોઈએ નહીં.
- રૂટ લેઆઉટમાં વન-શોટ લોજિક (one-shot logic) ટાળો. દરેક પેજ લોડ પર રેન્ડર થતા ઘટકમાં મૂકેલી કોઈપણ વસ્તુ વારંવાર એક્ઝિક્યુટ થશે, જેનાથી "દરેક મુલાકાતી માટે એક વાર" એ "દરેક પેજ વ્યુ માટે એક વાર" માં બદલાઈ જશે.
- જ્યારે અવલોકન કરેલ સ્પ્લિટ રેન્ડમાઇઝરથી વિરુદ્ધ હોય, ત્યારે પહેલા કાઉન્ટરનું ઓડિટ કરો. ડેવલપર્સ ઘણીવાર રેન્ડમાઇઝરની નિષ્પક્ષતાની તપાસ કરે છે પરંતુ ગણતરી કરવાની પદ્ધતિ સચોટ છે કે નહીં તેની ભાગ્યે જ ચકાસણી કરે છે.
આગળ શું ધ્યાન રાખવું
એક્સપોઝર માટે સિંગલ કાઉન્ટર પર આધાર રાખતા કોઈપણ પ્રયોગનું ઓડિટ કરવું જોઈએ કે તે કાઉન્ટર કમ્પોનન્ટ ટ્રી (component tree) માં ક્યાં આવેલું છે. જો કાઉન્ટર ગ્લોબલ લેઆઉટમાં હોય, તો એક એવી તપાસ ઉમેરો જે ઇવેન્ટને પર્સિસ્ટન્ટ આઈડેન્ટિફાયર (persistent identifier)—જેમ કે કૂકી અથવા લોકલ-સ્ટોરેજ ફ્લેગ—સાથે જોડે. ટીમોએ તેમના ડેશબોર્ડમાં સેનિટી ચેક (sanity check) પણ બનાવવો જોઈએ: જો અવલોકન કરેલ વેરિઅન્ટ વિતરણ નાના આંકડાકીય માર્જિનથી વધુ વિચલિત થાય, તો રેન્ડમાઇઝર બગડી ગયું છે તેમ માની લેવાને બદલે કાઉન્ટર ઓડિટ માટે ટેસ્ટને ફ્લેગ કરો.
ટૂંકમાં, વિશ્વસનીય એક્સપોઝર કાઉન્ટ વગર સારી રીતે કામ કરતું રેન્ડમાઇઝર નકામું છે. જવાબદારીઓને વહેંચવી અને વન-ઓફ ઇવેન્ટ્સને હંમેશા રેન્ડર થતા ઘટકોની બહાર રાખવાથી A/B ટેસ્ટ સચોટ રહે છે અને અઠવાડિયાના બિનજરૂરી વિશ્લેષણનો બચાવ થાય છે.