ಸೈಟ್ನ ರೂಟ್ ಲೇಔಟ್ನಲ್ಲಿರುವ ಒಂದು ಹಂಚಿಕೆಯ ಫಂಕ್ಷನ್ (shared function), A/B-ಟೆಸ್ಟ್ ಎಕ್ಸ್ಪೋಸರ್ ಕೌಂಟರ್ ಅನ್ನು ಪೇಜ್-ವ್ಯೂ ಕೌಂಟರ್ ಆಗಿ ಬದಲಾಯಿಸಿತು, ಇದರಿಂದ ಸ್ಯಾಂಪಲ್ ಗಾತ್ರವು ಅತಿಯಾಗಿ ಹೆಚ್ಚಾಗಿ ಕನ್ವರ್ಷನ್ ದರಗಳು ಅರ್ಥಹೀನವಾದವು. ಹೋಮ್ಪೇಜ್ನ 50/50 ವಿಭಜನೆಯಾಗಿದ್ದ ಈ ಪರೀಕ್ಷೆಯು, ಒಂದು ವೇರಿಯಂಟ್ಗೆ 178 ಹಿಟ್ಗಳನ್ನು ಮತ್ತು ಇನ್ನೊಂದಕ್ಕೆ 57 ಹಿಟ್ಗಳನ್ನು ವರದಿ ಮಾಡಿತು—ಇದು ನಿರೀಕ್ಷಿತ ಸಮಾನ ವಿಭಜನೆಯಿಂದ ಬಹಳ ದೂರವಿತ್ತು.
ಈ ದೋಷವು ರ್ಯಾಂಡೊಮೈಜರ್ನಿಂದ ತಪ್ಪಿಹೋಗಿದ್ದು ಹೇಗೆ
ಡೆವಲಪರ್ ಮೊದಲು ವಿಸಿಟರ್ಗಳನ್ನು ಒಂದು ವೇರಿಯಂಟ್ಗೆ ನಿಯೋಜಿಸುವ ರ್ಯಾಂಡೊಮೈಜರ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದನು. ಅವನು ಮಿಡ್ಲ್ವೇರ್ ಅನ್ನು ಓದಿದನು, ಕುಕಿ ಲಾಜಿಕ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿದನು ಮತ್ತು ಅಸೈನ್ಮೆಂಟ್ ಫಂಕ್ಷನ್ ಅನ್ನು 10,000 ಬಾರಿ ಕರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಚಲಾಯಿಸಿದನು; ಅದು ಪರಿಪೂರ್ಣ 50/50 ವಿಭಜನೆಯನ್ನು ನೀಡಿತು. ರ್ಯಾಂಡೊಮೈಜರ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು; ಸಮಸ್ಯೆ ಎಕ್ಸ್ಪೋಸರ್ ಅನ್ನು ಹೇಗೆ ದಾಖಲಿಸಲಾಗುತ್ತಿದೆ ಎಂಬುದರಲ್ಲಿತ್ತು.
ಒಂದು ಫಂಕ್ಷನ್ ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಿತ್ತು:
- ವೇರಿಯಂಟ್ ಅನ್ನು ಸೆಟ್ ಮಾಡುವುದು (Set the variant) – ವಿಸಿಟರ್ನ ಅನುಭವವು ಸ್ಥಿರವಾಗಿರಲು ಪ್ರತಿ ಪೇಜ್ ಲೋಡ್ ಆದಾಗಲೂ ಇದು ಚಲಿಸುತ್ತದೆ.
- ಎಕ್ಸ್ಪೋಸರ್ ಇವೆಂಟ್ ಅನ್ನು ದಾಖಲಿಸುವುದು (Record the exposure event) – ವೇರಿಯಂಟ್ ಮೊದಲ ಬಾರಿಗೆ ಕಾಣಿಸಿಕೊಂಡ ಕ್ಷಣದಲ್ಲಿ, ಪ್ರತಿ ವಿಸಿಟರ್ಗೆ ಕೇವಲ ಒಂದು ಬಾರಿ ಮಾತ್ರ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು.
ಈ ಫಂಕ್ಷನ್ ರೂಟ್ ಲೇಔಟ್ನಲ್ಲಿತ್ತು, ಇದು ಪ್ರತಿ ನ್ಯಾವಿಗೇಷನ್ನಲ್ಲಿಯೂ ರೆಂಡರ್ ಆಗುವ ಒಂದು ಕಾಂಪೊನೆಂಟ್ ಆಗಿದೆ. ಎಕ್ಸ್ಪೋಸರ್-ರೆಕಾರ್ಡಿಂಗ್ ಕೋಡ್ ಪ್ರತಿ ಬಾರಿ ಲೇಔಟ್ ರೆಂಡರ್ ಆದಾಗಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರಿಂದ, ಪ್ರತಿ ಪೇಜ್ ವ್ಯೂ ಕೂಡ ಹೊಸ ಎಕ್ಸ್ಪೋಸರ್ ಆಗಿ ಎಣಿಕೆಯಾಯಿತು. ಎರಡು ಹೋಮ್ಪೇಜ್ ವೇರಿಯಂಟ್ಗಳು ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ಲೇಔಟ್ ಟ್ರೀಗಳನ್ನು ಬಳಸಿದ್ದವು, ಆದ್ದರಿಂದ ಅವುಗಳ ಪೇಜ್-ವ್ಯೂ ದರಗಳು ವ್ಯತ್ಯಾಸವಾದವು, ಇದು ರ್ಯಾಂಡೊಮೈಜರ್ ಕೆಟ್ಟಿದೆ ಎಂಬ ಭ್ರಮೆಯನ್ನು ಸೃಷ್ಟಿಸಿತು.
ಈ ತಪ್ಪಾದ ಎಣಿಕೆಯು ಏಕೆ ಮುಖ್ಯವಾಯಿತು
ಕನ್ವರ್ಷನ್ ಸಂಖ್ಯೆಗಳು—ಕ್ಲಿಕ್-ತ್ರುಗಳು, ಸೈನ್-ಅಪ್ಗಳು, ಖರೀದಿಗಳು—ಸರಿಯಾಗಿ ದಾಖಲಾಗಿದ್ದವು. ಆದರೆ ಛೇದ (denominator - ಎಕ್ಸ್ಪೋಸರ್ ಸಂಖ್ಯೆ) ತಪ್ಪಾಗಿತ್ತು. ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ ಕನ್ವರ್ಷನ್ ದರಗಳು ವಾಸ್ತವಕ್ಕಿಂತ ಬಹಳ ಕಡಿಮೆ ಕಂಡುಬಂದವು ಮತ್ತು ಆ ದರಗಳ ಆಧಾರದ ಮೇಲೆ ತೆಗೆದುಕೊಳ್ಳುವ ಯಾವುದೇ ನಿರ್ಧಾರಗಳು ಅನಂಬಿಕವಾಗಿದ್ದವು.
ಈ ವ್ಯತ್ಯಾಸವು ತಿಳಿಯುವ ಮೊದಲು ಪರೀಕ್ಷೆಯು ಎರಡು ವಾರಗಳ ಕಾಲ ನಡೆಯಿತು, ಇದು ತಂಡವು ಇಡೀ ಡೇಟಾ ಸೆಟ್ ಅನ್ನು ಕೈಬಿಡುವಂತೆ ಮಾಡಿತು.
ಪರಿಹಾರ
ಪರಿಹಾರ ಸರಳವಾಗಿತ್ತು: ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಫಂಕ್ಷನ್ಗಳಾಗಿ ವಿಭಜಿಸುವುದು. ಎಕ್ಸ್ಪೋಸರ್-ರೆಕಾರ್ಡಿಂಗ್ ಕೋಡ್ ಈಗ ವಿಸಿಟರ್ ಅನ್ನು ಈಗಾಗಲೇ ಎಣಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ ಕೇವಲ ಒಂದು ಬಾರಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವೇರಿಯಂಟ್-ಸೆಟ್ಟಿಂಗ್ ಕೋಡ್ ಇದ್ದಲ್ಲೇ ಇರುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ನ್ಯಾವಿಗೇಷನ್ನಲ್ಲಿಯೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.
ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸುವ ಯಾರಿಗಾದರೂ ಮೂರು ಪ್ರಮುಖ ಅಂಶಗಳು
- ಸ್ಟೇಟ್-ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಒನ್-ಆಫ್ ಇವೆಂಟ್ಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. ವೇರಿಯಂಟ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಮತ್ತು ಎಕ್ಸ್ಪೋಸರ್ ಅನ್ನು ಲಾಗ್ ಮಾಡುವ ಎರಡೂ ಕೆಲಸಗಳನ್ನು ಮಾಡುವ ಒಂದು ಫಂಕ್ಷನ್ ಸಂಘರ್ಷಕ್ಕೆ ಒಳಗಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಮೊದಲನೆಯದು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ ಆದರೆ ಎರಡನೆಯದು ಹಾಗಾಗಬಾರದು.
- ರೂಟ್ ಲೇಔಟ್ನಲ್ಲಿ ಒನ್-ಶಾಟ್ ಲಾಜಿಕ್ ಅನ್ನು ತಪ್ಪಿಸಿ. ಪ್ರತಿ ಪೇಜ್ ಲೋಡ್ ಆದಾಗಲೂ ರೆಂಡರ್ ಆಗುವ ಕಾಂಪೊನೆಂಟ್ನಲ್ಲಿ ಇರಿಸಲಾದ ಯಾವುದೇ ವಿಷಯವು ಪದೇ ಪದೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು "ಪ್ರತಿ ವಿಸಿಟರ್ಗೆ ಒಂದು ಬಾರಿ" ಎಂಬುದನ್ನು "ಪ್ರತಿ ಪೇಜ್ ವ್ಯೂಗೆ ಒಂದು ಬಾರಿ" ಎಂದು ಬದಲಾಯಿಸುತ್ತದೆ.
- ವೀಕ್ಷಿಸಿದ ವಿಭಜನೆಯು ರ್ಯಾಂಡೊಮೈಜರ್ಗೆ ವಿರುದ್ಧವಾಗಿದ್ದಾಗ, ಮೊದಲು ಕೌಂಟರ್ ಅನ್ನು ಆಡಿಟ್ ಮಾಡಿ. ಡೆವಲಪರ್ಗಳು ಹೆಚ್ಚಾಗಿ ರ್ಯಾಂಡೊಮೈಜರ್ನ ನ್ಯಾಯಸಮ್ಮತತೆಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ ಆದರೆ ಎಣಿಕೆಯ ಕಾರ್ಯವಿಧಾನವು ನಿಖರವಾಗಿದೆಯೇ ಎಂದು ಅಪರೂಪಕ್ಕೆ ಮಾತ್ರ ಪರಿಶೀಲಿಸುತ್ತಾರೆ.
ಮುಂದೆ ಯಾವುದನ್ನು ಗಮನಿಸಬೇಕು
ಎಕ್ಸ್ಪೋಸರ್ನಿಗಾಗಿ ಒಂದೇ ಕೌಂಟರ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಪ್ರಯೋಗವನ್ನು, ಆ ಕೌಂಟರ್ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀನಲ್ಲಿ ಎಲ್ಲಿ ನೆಲೆಸಿದೆ ಎಂಬುದರ ಮೇಲೆ ಆಡಿಟ್ ಮಾಡಬೇಕು. ಕೌಂಟರ್ ಗ್ಲೋಬಲ್ ಲೇಔಟ್ನಲ್ಲಿ ಇದ್ದರೆ, ಕುಕಿ ಅಥವಾ ಲೋಕಲ್-ಸ್ಟೋರೇಜ್ ಫ್ಲಾಗ್ನಂತಹ ಸ್ಥಿರ ಗುರುತಿಗೆ (persistent identifier) ಇವೆಂಟ್ ಅನ್ನು ಜೋಡಿಸುವ ಪರಿಶೀಲನೆಯನ್ನು ಸೇರಿಸಿ. ತಂಡಗಳು ತಮ್ಮ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳಲ್ಲಿ ಸ್ಯಾನಿಟಿ ಚೆಕ್ ಅನ್ನು ಸಹ ನಿರ್ಮಿಸಬೇಕು: ವೀಕ್ಷಿಸಿದ ವೇರಿಯಂಟ್ ವಿತರಣೆಯು ಸಣ್ಣ ಸಾಂಖ್ಯಿಕ ಮಾರ್ಜಿನ್ನಿಂದ ಹೊರಬಿದ್ದರೆ, ರ್ಯಾಂಡೊಮೈಜರ್ ಕೆಟ್ಟಿದೆ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಕೌಂಟರ್ ಆಡಿಟ್ಗಾಗಿ ಪರೀಕ್ಷೆಯನ್ನು ಫ್ಲಾಗ್ ಮಾಡಿ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಂಬಿಕಾರ್ಹ ಎಕ್ಸ್ಪೋಸರ್ ಎಣಿಕೆಯಿಲ್ಲದೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ರ್ಯಾಂಡೊಮೈಜರ್ ಕೂಡ ಪ್ರಯೋಜನವಿಲ್ಲದಂತಾಗುತ್ತದೆ. ಜವಾಬ್ದಾರಿಗಳನ್ನು ವಿಭಜಿಸುವುದು ಮತ್ತು ಒನ್-ಆಫ್ ಇವೆಂಟ್ಗಳನ್ನು ಯಾವಾಗಲೂ ರೆಂಡರ್ ಆಗುವ ಕಾಂಪೊನೆಂಟ್ಗಳ ಹೊರಗೆ ಇರಿಸುವುದು A/B ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಖರವಾಗಿಡುತ್ತದೆ ಮತ್ತು ವಾರಗಟ್ಟಲೆ ವ್ಯರ್ಥವಾಗುವ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಉಳಿಸುತ್ತದೆ.