ਸਾਈਟ ਦੇ ਰੂਟ ਲੇਆਉਟ (root layout) ਵਿੱਚ ਇੱਕ ਸਾਂਝੇ ਫੰਕਸ਼ਨ ਨੇ A/B-ਟੈਸਟ ਐਕਸਪੋਜ਼ਰ ਕਾਊਂਟਰ (exposure counter) ਨੂੰ ਪੇਜ-ਵਿਊ ਕਾਊਂਟਰ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਸੈਂਪਲ ਸਾਈਜ਼ ਵਧ ਗਿਆ ਅਤੇ ਕਨਵਰਜ਼ਨ ਰੇਟ (conversion rates) ਬੇਮਤਲਬ ਹੋ ਗਏ। ਹੋਮਪੇਜ ਦੇ 50/50 ਸਪਲਿਟ ਵਾਲੇ ਇਸ ਟੈਸਟ ਵਿੱਚ, ਇੱਕ ਵੇਰੀਐਂਟ (variant) ਲਈ 178 ਹਿੱਟਸ ਅਤੇ ਦੂਜੇ ਲਈ 57 ਰਿਪੋਰਟ ਕੀਤੇ ਗਏ—ਜੋ ਕਿ ਉਮੀਦ ਕੀਤੇ ਸਮਾਨ ਸਪਲਿਟ ਤੋਂ ਬਹੁਤ ਦੂਰ ਸਨ।
ਗਲਤੀ ਰੈਂਡਮਾਈਜ਼ਰ (randomizer) ਤੋਂ ਕਿਵੇਂ ਬਚ ਨਿਕਲੀ
ਡਿਵੈਲਪਰ ਨੇ ਪਹਿਲਾਂ ਉਸ ਰੈਂਡਮਾਈਜ਼ਰ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜੋ ਵਿਜ਼ਿਟਰਾਂ ਨੂੰ ਵੇਰੀਐਂਟ ਅਲਾਟ ਕਰਦਾ ਹੈ। ਉਸਨੇ ਮਿਡਲਵੇਅਰ (middleware) ਨੂੰ ਪੜ੍ਹਿਆ, ਕੁਕੀ (cookie) ਲੌਜਿਕ ਦੀ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਇੱਕ ਸਕ੍ਰਿਪਟ ਚਲਾਈ ਜਿਸਨੇ ਅਸਾਈਨਮੈਂਟ ਫੰਕਸ਼ਨ ਨੂੰ 10,000 ਵਾਰ ਕਾਲ ਕੀਤਾ; ਇਸਨੇ ਇੱਕ ਬਿਲਕੁਲ ਸਹੀ 50/50 ਸਪਲਿਟ ਦਿੱਤਾ। ਰੈਂਡਮਾਈਜ਼ਰ ਖੁਦ ਸਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ; ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਕਿਵੇਂ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ।
ਇੱਕ ਸਿੰਗਲ ਫੰਕਸ਼ਨ ਦੋ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ:
- ਵੇਰੀਐਂਟ ਸੈੱਟ ਕਰਨਾ (Set the variant) – ਵਿਜ਼ਿਟਰ ਦੇ ਅਨੁਭਵ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣ ਲਈ ਹਰ ਪੇਜ ਲੋਡ 'ਤੇ ਚੱਲਦਾ ਹੈ।
- ਐਕਸਪੋਜ਼ਰ ਇਵੈਂਟ ਰਿਕਾਰਡ ਕਰਨਾ (Record the exposure event) – ਇਹ ਵਿਜ਼ਿਟਰ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਹੀ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਪਲ ਵੇਰੀਐਂਟ ਪਹਿਲੀ ਵਾਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
ਇਹ ਫੰਕਸ਼ਨ ਰੂਟ ਲੇਆਉਟ (root layout) ਵਿੱਚ ਸੀ, ਜੋ ਹਰ ਨੈਵੀਗੇਸ਼ਨ 'ਤੇ ਰੈਂਡਰ (render) ਹੋਣ ਵਾਲਾ ਇੱਕ ਕੰਪੋਨੈਂਟ ਹੈ। ਕਿਉਂਕਿ ਐਕਸਪੋਜ਼ਰ-ਰਿਕਾਰਡਿੰਗ ਕੋਡ ਹਰ ਵਾਰ ਲੇਆਉਟ ਰੈਂਡਰ ਹੋਣ ਵੇਲੇ ਚੱਲਦਾ ਸੀ, ਇਸ ਲਈ ਹਰ ਪੇਜ ਵਿਊ ਨੂੰ ਇੱਕ ਨਵਾਂ ਐਕਸਪੋਜ਼ਰ ਮੰਨ ਲਿਆ ਗਿਆ। ਹੋਮਪੇਜ ਦੇ ਦੋਵੇਂ ਵੇਰੀਐਂਟਸ ਵੱਖ-ਵੱਖ ਲੇਆਉਟ ਟ੍ਰੀਜ਼ (layout trees) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਦੇ ਪੇਜ-ਵਿਊ ਰੇਟ ਵੱਖਰੇ ਹੋ ਗਏ, ਜਿਸ ਨਾਲ ਇਹ ਭਰਮ ਪੈਦਾ ਹੋਇਆ ਕਿ ਰੈਂਡਮਾਈਜ਼ਰ ਖਰਾਬ ਹੈ।
ਗਲਤ ਗਿਣਤੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ
ਕਨਵਰਜ਼ਨ ਨੰਬਰ—ਕਲਿੱਕ-ਥਰੂ (click-throughs), ਸਾਈਨ-ਅੱਪ (sign-ups), ਖਰੀਦਦਾਰੀ (purchases)—ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲੌਗ ਕੀਤੇ ਗਏ ਸਨ। ਪਰ ਡੈਨੋਮੀਨੇਟਰ (denominator - ਐਕਸਪੋਜ਼ਰ ਦੀ ਗਿਣਤੀ) ਗਲਤ ਸੀ। ਗਣਨਾ ਕੀਤੇ ਗਏ ਕਨਵਰਜ਼ਨ ਰੇਟ ਅਸਲੀਅਤ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਦਿਖਾਈ ਦਿੱਤੇ, ਅਤੇ ਉਹਨਾਂ ਰੇਟਾਂ 'ਤੇ ਅਧਾਰਤ ਕੋਈ ਵੀ ਫੈਸਲਾ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਸੀ।
ਇਸ ਅੰਤਰ (discrepancy) ਦੇ ਸਾਹਮਣੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਦੋ ਹਫ਼ਤਿਆਂ ਤੱਕ ਚੱਲਿਆ, ਜਿਸ ਕਾਰਨ ਟੀਮ ਨੂੰ ਸਾਰਾ ਡੇਟਾ ਸੈੱਟ ਰੱਦ ਕਰਨਾ ਪਿਆ।
ਹੱਲ
ਹੱਲ ਸਿੱਧਾ ਸੀ: ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡ ਦਿੱਤਾ ਗਿਆ। ਐਕਸਪੋਜ਼ਰ-ਰਿਕਾਰਡਿੰਗ ਕੋਡ ਹੁਣ ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਵਿਜ਼ਿਟਰ ਦੀ ਗਿਣਤੀ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਹਰ ਯੂਜ਼ਰ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਹੀ ਚੱਲਦਾ ਹੈ। ਵੇਰੀਐਂਟ-ਸੈੱਟਿੰਗ ਕੋਡ ਆਪਣੀ ਜਗ੍ਹਾ 'ਤੇ ਹੀ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਹਰ ਨੈਵੀਗੇਸ਼ਨ 'ਤੇ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ।
ਪ੍ਰਯੋਗ (experiments) ਚਲਾਉਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਤਿੰਨ ਮੁੱਖ ਗੱਲਾਂ
- ਸਟੇਟ-ਸੈਟਿੰਗ (state-setting) ਨੂੰ ਵਨ-ਆਫ ਇਵੈਂਟਸ (one-off events) ਤੋਂ ਵੱਖ ਰੱਖੋ। ਇੱਕ ਅਜਿਹਾ ਫੰਕਸ਼ਨ ਜੋ ਵੇਰੀਐਂਟ ਅਲਾਟ ਵੀ ਕਰਦਾ ਹੈ ਅਤੇ ਐਕਸਪੋਜ਼ਰ ਲੌਗ ਵੀ ਕਰਦਾ ਹੈ, ਉਹ ਟਕਰਾਵੇਗਾ ਕਿਉਂਕਿ ਪਹਿਲਾ ਵਾਰ-ਵਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
- ਰੂਟ ਲੇਆਉਟ ਵਿੱਚ ਵਨ-ਸ਼ੌਟ ਲੌਜਿਕ (one-shot logic) ਤੋਂ ਬਚੋ। ਕਿਸੇ ਅਜਿਹੇ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਰੱਖੀ ਗਈ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਹਰ ਪੇਜ ਲੋਡ 'ਤੇ ਰੈਂਡਰ ਹੁੰਦੀ ਹੈ, ਉਹ ਵਾਰ-ਵਾਰ ਚੱਲੇਗੀ, ਜਿਸ ਨਾਲ "ਇੱਕ ਵਿਜ਼ਿਟਰ ਪ੍ਰਤੀ ਇੱਕ ਵਾਰ" ਬਦਲ ਕੇ "ਇੱਕ ਪੇਜ ਵਿਊ ਪ੍ਰਤੀ ਇੱਕ ਵਾਰ" ਹੋ ਜਾਵੇਗਾ।
- ਜਦੋਂ ਦੇਖਿਆ ਗਿਆ ਸਪਲਿਟ ਰੈਂਡਮਾਈਜ਼ਰ ਦੇ ਉਲਟ ਹੋਵੇ, ਤਾਂ ਪਹਿਲਾਂ ਕਾਊਂਟਰ ਦੀ ਜਾਂਚ ਕਰੋ। ਡਿਵੈਲਪਰ ਅਕਸਰ ਰੈਂਡਮਾਈਜ਼ਰ ਦੀ ਨਿਰਪੱਖਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ ਪਰ ਬਹੁਤ ਘੱਟ ਹੀ ਇਹ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ ਗਿਣਤੀ ਕਰਨ ਵਾਲੀ ਵਿਧੀ (counting mechanism) ਸਹੀ ਹੈ।
ਅੱਗੇ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਹੈ
ਕੋਈ ਵੀ ਪ੍ਰਯੋਗ ਜੋ ਐਕਸਪੋਜ਼ਰ ਲਈ ਇੱਕ ਸਿੰਗਲ ਕਾਊਂਟਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਉਸ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਹ ਕਾਊਂਟਰ ਕੰਪੋਨੈਂਟ ਟ੍ਰੀ (component tree) ਵਿੱਚ ਕਿੱਥੇ ਹੈ। ਜੇਕਰ ਕਾਊਂਟਰ ਇੱਕ ਗਲੋਬਲ ਲੇਆਉਟ ਵਿੱਚ ਹੈ, ਤਾਂ ਇੱਕ ਅਜਿਹਾ ਚੈੱਕ ਜੋੜੋ ਜੋ ਇਵੈਂਟ ਨੂੰ ਇੱਕ ਪੱਕੇ ਆਈਡੈਂਟੀਫਾਇਰ (persistent identifier)—ਜਿਵੇਂ ਕਿ ਕੁਕੀ ਜਾਂ ਲੋਕਲ-ਸਟੋਰੇਜ ਫਲੈਗ (local-storage flag)— ਨਾਲ ਜੋੜਦਾ ਹੋਵੇ। ਟੀਮਾਂ ਨੂੰ ਆਪਣੇ ਡੈਸ਼ਬੋਰਡਾਂ ਵਿੱਚ ਇੱਕ ਸੈਨਿਟੀ ਚੈੱਕ (sanity check) ਵੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ: ਜੇਕਰ ਦੇਖਿਆ ਗਿਆ ਵੇਰੀਐਂਟ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਇੱਕ ਛੋਟੇ ਅੰਕੜਾ ਵਿਗਿਆਨਕ ਮਾਰਜਿਨ ਤੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੈਂਡਮਾਈਜ਼ਰ ਦੇ ਖਰਾਬ ਹੋਣ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਊਂਟਰ ਦੀ ਜਾਂਚ ਲਈ ਟੈਸਟ ਨੂੰ ਫਲੈਗ ਕਰੋ।
ਸੰਖੇਪ ਵਿੱਚ, ਇੱਕ ਭਰੋਸੇਯੋਗ ਐਕਸਪੋਜ਼ਰ ਕਾਊਂਟ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰੈਂਡਮਾਈਜ਼ਰ ਬੇਕਾਰ ਹੈ। ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਵੰਡਣਾ ਅਤੇ ਵਨ-ਆਫ ਇਵੈਂਟਸ ਨੂੰ ਹਮੇਸ਼ਾ ਰੈਂਡਰ ਹੋਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟਸ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ A/B ਟੈਸਟਾਂ ਨੂੰ ਸਹੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਹਫ਼ਤਿਆਂ ਦੀ ਬੇਕਾਰ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।