[ 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: 1789836189982.jpg (311.64 KB, 1024x1024, img_1789836176487_3v2643nd.jpg)ImgOps Exif Google Yandex

9cb56 No.2196[Reply]

finally figured out why our storage costs are such a mess lately. it's not even about the compute or dbus, it's just all those stupid nightly exports and duplicate parquet files we're running to keep snowflake in sync with databricks. if unifrom actually works, we wouldn't need that extra layer of metadata just to read delta as iceberg.
>one copy of Parquet with multiple metadata layers describing it
sounds great on paper but i'm skeptical about how much latency we'd actually see on the snowflake side when writing. it's basically trying to kill the vendor lock-in by making the catalog irrelevant. good luck with the maintenance overhead though is anyone here actually running unifrom in production yet?

full read: https://hackernoon.com/delta-lake-uniform-is-the-real-fix-for-the-snowflake-vs-databricks-standoff?source=rss

9cb56 No.2217

>>2196
>it's just all those stupid nightly exports and duplicate parquet files we're running to keep snowflake in sync with databricks

The duplication is exactly what kills my budget too. Are you currently using a specific orchestration tool to manage those nightly exports, or is it just a mess of custom scripts?



File: 1790214659394.jpg (206.63 KB, 1024x1024, img_1790214651382_a1l3ju3o.jpg)ImgOps Exif Google Yandex

68ab6 No.2216[Reply]

I'm tired of seeing people use stacked area charts to show percent change in conversions. It makes it impossible to actually read the baseline for the top layers when the bottom layer fluctuates wildly. Just use a standard line chart or even a simple bar graph if you want to be helpful clear.

It's basically just a visual lie at that point


File: 1790171963320.jpg (157.41 KB, 1024x1024, img_1790171954984_qy8abknr.jpg)ImgOps Exif Google Yandex

aa66d No.2214[Reply]

it's basically just common knowledge that js snippets do most of the heavy lifting for pageviews and custom events like form fills. server logs are fine if you want to see everything including the bots, but it feels like a lot of unnecessary noise when you're just trying to check an assumption about checkout friction. anyone actually bother with server-side tracking anymore?

https://plausible.io/blog/web-analytics


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.



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 ]