3 ms·
The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to o
by CM30 2y ago
The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.
- csswizardry 2y agoHonestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.
- wizzwizz4 2y agoBut sorting all the paragraphs in alphabetical order increased reader engagement metrics! How would I ever have discovered readers wanted that without A/B testing?
- CM30 2y agoIdeally it should be on the server side, so you're right there. Client side A/B testing isn't the best way to handle things. However, it's sometimes a necessary evil due to: 1. The original company not budgeting time/effort from their existing dev teams to work on A/B testing, and wanting to outsource it instead. 2. Said company and their tech department being nervous about letting outsiders actually access the source code for their site/app. 3. Or said company wanting the analytics/features that VWO/Target/Optimisely/whatever offer, and not wanting to have code up the same analytics toolbox themself.
- csswizardry 2y agoAll three of your points are correct, so please don’t resent my response: Client-side A/B testing exists because ‘we should be able to do this without a deploy’. And they’re right.