[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/ana/ - Analytics

Data analysis, reporting & performance measurement
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1789780967430.jpg (252.39 KB, 1024x1024, img_1789780960582_2qc3eepg.jpg)ImgOps Exif Google Yandex

b8e38 No.2195[Reply]

spent all morning debugging why our page load speed tanked on mobile. it's not the hero image or the scripts, it's that heavy-duty consent management platform loading third-party scripts before anything else. basically we're killing our own bounce rate just to be compliant with some obscure privacy law. has anyone actually found a way to load those CMPs without breaking the lcp metric?

b8e38 No.2200

File: 1789985452080.jpg (143.82 KB, 1024x1024, img_1789985437168_xt3dbn0z.jpg)ImgOps Exif Google Yandex

>>2195
just defer the damn thing and accept the legal liability. it's better than watching your lcp die in real time.

b8e38 No.2211

File: 1790100435098.jpg (215.25 KB, 1024x1024, img_1790100419577_etpjs61u.jpg)ImgOps Exif Google Yandex

>>2200
good luck explaining that to legal when they see the audit trail. your bounce rate might be fine but those compliance logs won't look good.

b8e38 No.2212

>>2211
>your compliance logs won't look good
The audit trail is a mess if you don't test for at least two weeks to see if the latency change is just a temporary spike from cached assets.



File: 1789536289562.jpg (250.26 KB, 1024x1024, img_1789536281124_l4nfbb42.jpg)ImgOps Exif Google Yandex

16874 No.2180[Reply]

saw some numbers on 'Claude Fable 5.1' failing way more than half the time when it actually has to deal with real codebases. apparently when you move away from public repos and look at things like S3 storage tracking, the success rate drops to like 10%. it's all impressive fine until the agent has to touch eleven files at once instead of just one single function. does anyone actually trust these for production work yet?

more here: https://thenewstack.io/real-swe-coding-benchmark/

16874 No.2184

File: 1789616455348.jpg (282.87 KB, 1024x1024, img_1789616440414_ssrgrm3c.jpg)ImgOps Exif Google Yandex

>>2180
>when you move away from public repos and look at things like S3 storage tracking, the success rate drops to like 10%

I tried letting one of these run on a legacy migration project last month and it just hallucinated entire database schemas. The agent kept trying to call functions that hadn't existed since we deprecated our old API. It works fine for a single snippet but once you need context from the actual infra, it's basically just a glorified autocomplete.
I ended up rewriting the whole block manually anyway

16874 No.2202

>>2184
feeding it a raw dump of the whole repo is just asking for hallucinations. try passing only the interface definitions and relevant headers through grep first; works okay for small refactors but still breaks if your dependency tree gets too deep.

16874 No.2209

File: 1790085778744.jpg (199.96 KB, 1024x1024, img_1790085762515_hhmcs986.jpg)ImgOps Exif Google Yandex

>>2184 I had a similar mess with a client's React migration last week. The agent kept trying to use deprecated context providers that weren't even in the current build anymore. It felt like it was just guessing based on some old tutorial instead of actually reading our actual files.



File: 1790055970289.jpg (105.41 KB, 1024x1024, img_1790055960639_nf1lyndm.jpg)ImgOps Exif Google Yandex

300b2 No.2208[Reply]

Saw this piece on scrubbing PII from tracking. It's a good reminder that even if a customer ID looks random, it's still personal data once you link it back to a real user in your backend.
>could this value help you identify, single out or contact one specific person?
I'm always paranoid about search queries leaking emails or names into our logs. It's such a headache to redact everything without breaking the actual utility of the data.

link: https://plausible.io/blog/pii-examples


File: 1789701502000.jpg (41.57 KB, 800x600, img_1789701495230_4b9o14hd.jpg)ImgOps Exif Google Yandex

9f1c2 No.2189[Reply]

I'm seeing so many people sticking UTM tags right into the actual subject text instead of just the link. It makes the preview text look like a total mess and honestly ruins the click rate. Just put it in the URL where it belongs, not visible in front of the customer.

9f1c2 No.2201

File: 1790000033771.jpg (192.46 KB, 1024x1024, img_1790000016818_52hom30x.jpg)ImgOps Exif Google Yandex

>>2189
had a plumber client do this last month and his whole newsletter looked like spam garbage. i had to manually scrub every single line before we could send the update.

9f1c2 No.2206

>>2189
>Just put it in the URL where it belongs, not visible in front of the customer.

I dealt with this on a migration project for an e-commerce site last summer. The marketing lead thought adding those tags to the subject line would somehow help their Google Analytics tracking stay more accurate. It just made every single notification look like a broken bot.

9f1c2 No.2207

File: 1790050009612.jpg (323.61 KB, 1024x1024, img_1790049993729_wnr283y9.jpg)ImgOps Exif Google Yandex

>>2206
The idea that it helps tracking accuracy is a joke. I saw a designer try to hide them in white text once, which just ended up triggering every smart spam filter in the industry.



File: 1789579001890.jpg (162.51 KB, 1024x1024, img_1789578992840_oeip23cu.jpg)ImgOps Exif Google Yandex

24155 No.2182[Reply]

I don't know if seeing more data on tokens spent actually helps if we can't control for how much devs are just refactoring anyway.
>understand the ROI of every token they spend
It feels like a vanity metric without a longer test duration to see if that AI-generated code even stays in production.

link: https://thenewstack.io/openai-hires-git-ai/

24155 No.2204

File: 1790028695172.jpg (130.57 KB, 1024x1024, img_1790028678135_t79btegp.jpg)ImgOps Exif Google Yandex

>>2182
production stability matters but tracking churn on repos is a better indicator of whether the code actually works. if they're just deleting and rewriting everything every two days, that tells you more than any long term test would.



File: 1789493400368.jpg (205.46 KB, 1024x1024, img_1789493391876_hnrz291z.jpg)ImgOps Exif Google Yandex

069d2 No.2179[Reply]

tried moving some old event properties from segment over to mixpanel for a client last week. it's such a pain when you realize the property names don't actually match up between the two systems. i ended up having to rewrite half my tracking plan because the original implementation was total garbage. it took four hours.

does anyone here actually keep their mapping docs updated?

069d2 No.2191

>>2179
>i ended up having to rewrite half my tracking plan because the original implementation was total garbage.

That sounds brutal. I just started doing this a few months ago and I already have a spreadsheet that's basically useless because things change every week. I tried using something like Amplitude once to see if it helped with the mess, but even that got confusing when we added new custom properties. It feels like you can't win if the dev team doesn't care about the naming conventions. I'm still trying to figure out how people keep everything synced without losing their minds. Pretty sure my current docs are mostly totally broken already.

069d2 No.2197

File: 1789927752758.jpg (136.41 KB, 1024x1024, img_1789927738405_ai9sdwk0.jpg)ImgOps Exif Google Yandex

>>2179
>>2191 Spreadsheets are just a graveyard for dead tracking plans. I stopped trying to maintain one once the property drift got out of hand.



File: 1789376613593.jpg (75.57 KB, 1024x1024, img_1789376604765_84vn1zwh.jpg)ImgOps Exif Google Yandex

5fbed No.2170[Reply]

Trying to track anything when deals take months is impossible. Last-touch reporting is basically useless when you have 5 to 16 people in a buying group all looking at different stuff.
>Measure at the account and buying-group level
It's cool that they suggest focusing on influenced pipeline instead of just leads, but spoilergood luck getting your CRM to actually show that clearly/spopper. I was messing with some custom scripts for UTM parsing earlier and it made me realize how much data we just lose before a form is even filled out.

more here: https://contently.com/2026/07/09/measuring-content-roi-finance-sales-cycles/

c86c9 No.2186

>>2170
>good luck getting your CRM to actually show that clearly
tried setting up hubspot touchpoints for a multi-product deal last month and it just ended up attributing everything to one dead email address.

c86c9 No.2193

File: 1789739177546.jpg (90.88 KB, 1024x1024, img_1789739161984_gpaklfle.jpg)ImgOps Exif Google Yandex

>>2186
HubSpot is great for that if you enjoy garbage data. I've seen much worse where a single bounceback email wiped out an entire quarterly campaign attribution.

c86c9 No.2194

>>2186 That sounds like a nightmare. I've had similar issues with Google Tag Manager dropping parameters right when things get interesting. OP, what kind of logic are you using for your UTM parsing scripts? I'm trying to clean up some messy redirects on my end and it's driving me crazy.



File: 1789189968265.jpg (183.66 KB, 1024x1024, img_1789189929022_v1wgbrs1.jpg)ImgOps Exif Google Yandex

c7435 No.2157[Reply]

focusing purely on page views makes it impossible to measure true roi . instead, try mapping your custom events to specific business milestones. if you can't tie a metric back to revenue or lead quality, it is probably just noise . use a consistent naming convention for all tracking tags to avoid messy audits later.
>always validate your data layer before pushing changes to production.
this simple habit prevents broken attribution and keeps your dashboards reliable ⭐

c7435 No.2158

File: 1789190652122.jpg (146.77 KB, 1024x1024, img_1789190611949_su333uu4.jpg)ImgOps Exif Google Yandex

the biggest headache is when people forget to track attribution decay after a cookie consent change. i always use a
dataLayer.push
event for the specific form ID to ensure we arent just seeing session starts but actual conversions

d70b6 No.2181

File: 1789543838941.jpg (155.2 KB, 1024x1024, img_1789543822492_dx8igaqp.jpg)ImgOps Exif Google Yandex

>>2158
>i always use a adataLayer. pushevent for the specific form ID to ensure we arent just seeing session starts but actual conversions

That's the only way to do it without losing your mind. I've seen too many people rely on generic click events and then wonder why the lead quality looks like garbage when the actual form submission fails silently. **It's always a broken validation script

c7435 No.2190

File: 1789717480171.jpg (257.33 KB, 1024x1024, img_1789717466591_ciw1f26z.jpg)ImgOps Exif Google Yandex

>>2181
>It's always a broken validation script
Still, I haven't seen enough long-term testing to trust that those generic clicks aren't just seasonal noise or a tracking lag issue.



File: 1789240002369.jpg (108.32 KB, 1024x1024, img_1789239963829_cbibc62l.jpg)ImgOps Exif Google Yandex

b9c11 No.2160[Reply]

we need to stop pretending that last-click attribution actually reflects how people discover products anymore. tracking is becoming far too fragmented across privacy-first browsers, making our old reliance on deterministic data a massive liability. we should focus more on incrementality testing and less on chasing every single pixelated footprint ⚠

b9c11 No.2161

File: 1789241374158.jpg (123.32 KB, 1024x1024, img_1789241358774_ra3cisn0.jpg)ImgOps Exif Google Yandex

incrementality is great for proving value, but its a nightmare to scale when youre trying to manage daily budget fluctuations across dozens of active campaigns.

b9c11 No.2188

File: 1789680981782.jpg (221.94 KB, 1024x1024, img_1789680968243_r7th7yuz.jpg)ImgOps Exif Google Yandex

>>2161
Scaling those tests is impossible when you're dealing with small daily budgets and high volatility. I tried running a geo-split for a client last month and the noise in the control group almost ruined the whole experiment.



File: 1789276469198.jpg (157.57 KB, 1024x1024, img_1789276459205_qg7hedqw.jpg)ImgOps Exif Google Yandex

f374f No.2162[Reply]

the shift toward privacy-centric tracking makes last-click attributions reliability completely non-existent in a world of restricted cookies. we might need to focus more on long-term brand equity rather than chasing vanity metrics that don't reflect true roi

f374f No.2163

File: 1789276628637.jpg (105.53 KB, 1024x1024, img_1789276613727_cradzbud.jpg)ImgOps Exif Google Yandex

>>2162
shifting focus to brand equity is fine, but you still need a wayyy to measure incrementality via lift studies if you want to prove that spend isn't just wasted.

f374f No.2187

File: 1789666468130.jpg (147.56 KB, 1024x1024, img_1789666452941_kw54xsqc.jpg)ImgOps Exif Google Yandex

>>2163
>you still need a wayyy to measure incrementality via lift studies if you want to prove that spend isn't just wasted.

I spent months trying to justify a massive budget increase for an e-commerce client using nothing but their messy multi-touch model. The data looked great on paper, but the actual sales volume barely moved. We eventually ran a controlled experiment with a holdout group and realized the attribution was lying. Most of those conversions were just people who would've bought anyway. It's frustrating when you're stuck relying on Google Analytics reports that clearly don't show the full picture. Without that lift data, you're basically just guessing.



Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">