(Yet even so, backend-triggered tracking is probably less privacy-intrusive than frontend-, even if you’re sending the data to Google or Facebook or whoever.)
More server side data harvesting will not make that less intrusive.
Tracking that makes your life better is useful. If Opendoor knows you are looking for a new house in Arizona, and they can show you just the right house before it's sold to someone else, isn't that fantastic?
That's part of living in a diverse world.
I don't know about you, but I don't want a myopic world for myself. The perfect ad targeting system removes my agency; decides what I want and can afford on my behalf; makes my world significantly smaller.
You don't have to decide between targeted personalized ads and their toxic rats tail, or no ads at all. There's a middle way called contextual ads which is bound to the topic you're consuming.
It's not just a choice between relevant and irrelevant ads, it's that plus many more factors. Even if ads were super accurate, I'd prefer irrelevant ads to having my personal habits finely catalogued in order to subconsciously affect my buying or voting choices. And it is subconscious. Anecdotally, I recently noticed I'd started to want a particular type of personal care accessory. I realized the only reason this happened is because I'd been subjected to dozens of ads for this item over several weeks. I have zero need for this item, zero interest in owning one four weeks ago (even though I already knew the product existed), and nobody would even know the difference if I had one or not!
It is possible to do targeted advertising without surreptitious tracking. I listen to podcasts and often buy through their promo links. I'm happy to tell the advertiser where I heard the ad, because I like the content. And it's all explicit - no spying required.
I don't actually need any ads, so this is a false choice.
I bought into this reasoning for some years until I realized that I never saw a useful ad (except on Facebook properties, which is ironic since they are the ones who know least about me as far as I can tell.)
Maybe? When I look at a couple houses to help get comps for a family member and I get innudated with real estate listings for somewhere I don't live and don't want to live for months, that's certainly not fantastic. See also car shopping, or really anything where one sale is valuable enough to target me.
Also fun --- when you look at documentation or ratea for a service provider when you're their number 1 customer, and ads for that service provider follow you around for weeks. Yeah, I guess I'm highly likely to buy, cause you put me in your SEC filings as a top customer.
1) Your site loads in under 3-4 seconds for any user.
2) The user is interested enough to wait 3-4 seconds until the page loads.
Then most issues will be solved.
The problem with ads in many cases is that the traffic they send is of very low quality or just bots. In the end you already know from your ads provider how many users they say they sent and you should always use that when calculating ad conversion rate.
Also note that using Cloudflare will count as bounced users who never actually even tried to load your page (bots, crawlers, scrapers, all HTTP requests).
100 ms max on backend processing, 500 ms max on first time to interaction. Client connection speeds matter, obviously. 3-4 seconds is get your fired ass out of here in my world.
Really wish I read this more. And not just for the landing page.
This doesn't bode well for the end of Moore's law. That is Moore's law in the performance sense, i.e. guaranteed future single-core performance increases [even if small], not Moore's law as in the the doubling transistor density.
Isn't Google's AMP just a bunch of Javascript too? So even their "fix" is just perpetuating the issue
Moore’s law is only about the latter, it says nothing about performance.
The parsing and execution of third-party javascript is definitely non-trivial if you profile it, especially on lower end devices.
Finally, browser download priority requires async and defer attributes on scripts (usually), or other clever ways of deferring loading.
This makes sense for a tool like Optimizely which has to block rendering.
> The parsing and execution of third-party javascript is definitely non-trivial if you profile it, especially on lower end devices.
Given that this is supposed to happen after the page has already loaded, does this matter? If the thing you are optimizing for is page load time, and it takes a few 100ms after the page has already loaded to run the JS, does that actually negatively impact the user experience?
> Finally, browser download priority requires async and defer attributes on scripts (usually), or other clever ways of deferring loading.
When you add third party JS, shouldn't this be taken care of for you? Scripts for adding third party JS should already make use of async and defer as needed. What's a case where you would need to actually think about async and defer when making use of third party JS?
Though after working with a few of these A/B testing vendors, I'm firmly convinced that you'd be better off long term implementing your own A/B testing service on top of some internal admin UI builder like Retool.
Lots of user experience professionals find utility in data that serves discovery and design sprints. Lots of product management professionals find utility in data that serves validating incremental feature engagement.
https://en.m.wikiquote.org/wiki/Turtles_all_the_way_down
In this context, I'm referring to the "trust us, it works" attitude that people who sell/provide analytics on front-end tracking use to justify their effort/expense. Based on experience, when you point out obvious problems doing analytics with JS, they keep repeating the mantra "but you _need_ front-end analytics" infinitely.
I was wondering when this was going to be the norm.
Can't block third parties for privacy if the first party talks to them behind the scenes.
(If I understand what this means)
edit: for the specific case of conversion tracking as mentioned in the article, I would hope that only referred by Facebook/Google would be reported.
The problem is that beyond whatever functionality the developer of the app intended to use the SDK for, it also does its own thing of stalking the user even if the app doesn't end up using any SDK features at all.
> We explicitly only changed the infra which served our landing pages, and kept the content - the HTML/CSS/JS - identical. Once the new infra was shown to work, we would begin to experiment with the website itself.
- http://alexeymk.com/2020/07/14/lies-damn-list-and-front-end-...
- Front end tracking did not lie, the people tracking it were not aware. If opendoor was spending on Ads, the marketing team would be the first to see a disparity between the clicks on an ad network and pageviews on their end.
- As such this is also a reason why you need to check your server hit logs with your Analytics.
- Where is the author is right it Frontend numbers being incorrect largely due to blockers
- His understanding of bounces is also incorrect. Bounce is when there is no second "interaction event", many marketing folks fake-fix the bounce rate, by sending a scroll event as an interaction event.
- I always tell people that analytics numbers are "signals", not "metrics", they are not accurate enough to be called "metrics"
Like you, I also work to make sure people understand that client side data is not necessarily accurate, but still refer to it as metrics and KPIs, just with the caviot that we should bank on consistancy over accuracy, keeping our analysis geared towards behavior and trends versus most business people's immediate desire to take it to an operational/business intelligence type place.
