[ 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: 1791177272829.jpg (312.72 KB, 1024x1024, img_1791177264442_b8vepi34.jpg)ImgOps Exif Google Yandex

e4f8a No.2280[Reply]

everyone is obsessing over prompt engineering but its actually all about those agentic entry points. if you arent building out the action layer with machine readable stuff you basically dont exist to these agents. pretty skeptical about how much effort this takes for smaller sites though. feels like a lot of overhead just to be "callable" good luck with that governance layer

more here: https://www.schemaapp.com/schema-markup/the-modern-data-stack-for-the-agentic-web/

e4f8a No.2293

>>2280
The overhead for that governance layer is a nightmare if you're trying to keep everything strictly schema-compliant. I've been tracking some latency spikes on our newer endpoints since we added more metadata, and it's hard to tell if it's the new validation logic or just bad luck. How long did you run your tests to see if the 'machine readable' parts actually improved conversion?

I'm still seeing a lot of hallucinated API calls on my end.

e4f8a No.2300

>>2293 validation logic is definitely the killer. spent three weeks last month trying to clean up a client's api documentation just so their new agent wouldn't hallucinate field types and break the checkout flow. it basically turned into a full-on data auditing project instead of actual tracking work. op is right about the overhead, too, because keeping those schemas updated without breaking everything else is exhausting.

e4f8a No.2302

>>2293
>How long did you run your tests to see if the 'machine readable' parts actually improved conversion?

Conversion is such a noisy metric for this. If you're looking at latency spikes, you should be watching error rates on those new endpoints instead of trying to find signal in conversion data that's likely just random seasonal variance.



File: 1791544258936.jpg (109.02 KB, 1024x1024, img_1791544250996_pi8r97n2.jpg)ImgOps Exif Google Yandex

e7c38 No.2301[Reply]

Saw this piece about social teams struggling to get anything done outside of marketing. Only 36% of companies actually use those insights for broader business decisions.
>That's when a data problem becomes a storytelling problem.
It's easy to point at a spike in comments about pricing, but turning that into something the product team cares about is such a headache. Most of the time it just ends up as another useless dashboard no one opens.

more here: https://sproutsocial.com/insights/storytelling-with-data/


File: 1790991979437.jpg (261.35 KB, 1024x1024, img_1790991970481_2maoucex.jpg)ImgOps Exif Google Yandex

cfcf2 No.2269[Reply]

been reading up on this whole eu-hosted mess and it's honestly exhausting. everyone loves to brag about having a frankfurt data center but that doesn't mean a thing if the company is still based in the states. even if your traffic is routed through eu infrastructure, if they're under us jurisdiction like 18 usc 2713 then the feds can basically demand whatever they want. it's pretty wild how much people ignore the 'possession, custody, or control' part of the law. i saw something about a tool storing data in germany but still being operated by a us entity and that's basically a huge red flag for anyone actually worried about gdpr. you can't just look at where the server sits and call it a day. we really need to start checking if the actual cloud providers or subprocessors are us-owned too. otherwise, what's the point of even bothering with different regions? i don't know if any of our current stacks actually meet the stricter requirements. anyone else auditing their vendor list for this lately?

link: https://plausible.io/blog/eu-hosted-analytics-vs-eu-owned-analytics

cfcf2 No.2296

>>2269
>if they're under us jurisdiction like 18 usc 2713 then the feds can basically demand whatever they want

Check the parent company list for every subprocessor in your DPA. This works fine for simple SAAS stacks, but it gets a nightmare if you have complex downstream dependencies.

cfcf2 No.2297

File: 1791502159055.jpg (308.77 KB, 1024x1024, img_1791502145183_n4s0nn89.jpg)ImgOps Exif Google Yandex

>>2269
checking parent companies is a decent start but it's basically useless for edge cases. you'd expect to find some actual legal autonomy in those contracts instead of just more layers of us-based shell companies. most people just look at the server location and stop there, which is how you end up with a massive compliance gap ⚠



File: 1791464949453.jpg (173.49 KB, 1024x1024, img_1791464939988_iqp7i350.jpg)ImgOps Exif Google Yandex

573f7 No.2294[Reply]

been trying to build this weekly report but the date range picker keeps defaulting to yesterday last month for no reason. it's driving me insane because i have to manually click through every single dimension just to see the actual numbers.
>the data looks fine in bigquery
it doesn't matter if the source is right when the visualization is lying to my face. i'm about two minutes away from switching back to excel

anyone else seeing this specific bug on the new connector?


File: 1791092541922.jpg (218.27 KB, 1024x1024, img_1791092533062_buhlto5h.jpg)ImgOps Exif Google Yandex

5847b No.2275[Reply]

it's wild seeing that google cpc is still more than double what we're seeing on meta, especially since lead conversion rates actually went up by 11% recently. i wonder if this lower cost for traffic campaigns is going to make people stop caring about intent and just chase cheap clicks instead.

https://www.wordstream.com/blog/facebook-ads-benchmarks-2026

5847b No.2287

>>2275
>i wonder if this lower cost for traffic campaigns is going to make people stop caring about intent and just chase cheap clicks instead.

Happened with a client in the SAAS space last quarter. We slashed the budget on Search to try and ride that Meta wave, and the dashboard looked great for about three days. Then the sales team started complaining because every single lead was basically junk or just clicking by accident. They had zero idea what our product even did. It's a total trap if you aren't watching the backend closely. We ended up pivoting back to high-intent keywords because those cheap clicks were costing us more in wasted time than the actual CPC difference.

5847b No.2289

File: 1791358447156.jpg (63.53 KB, 1024x1024, img_1791358431118_am04qzaq.jpg)ImgOps Exif Google Yandex

>>2287
>every single lead was basically junk or just clicking.

I saw the same thing with a retail account last month. The CVR looks fine on paper, but we haven't even run the test for a full complete month yet. I'm worried about attribution lag masking how bad those clicks actually are.

5847b No.2291

File: 1791386847790.jpg (81.8 KB, 1024x1024, img_1791386832173_zch67rdd.jpg)ImgOps Exif Google Yandex

>>2289 i think attribution lag is definitely a factor but i'd actually expect to see the quality drop even more noticeably once that window settles and we can see which users are actually sticking around.



File: 1790949266270.jpg (234.04 KB, 1024x1024, img_1790949260105_n1rxus09.jpg)ImgOps Exif Google Yandex

84e74 No.2266[Reply]

tried using the properties view but it keeps grouping everything into one giant bucket. i think my event property mapping is broken since it's not respecting the individual session parameters at all.

84e74 No.2281

File: 1791178116998.jpg (228.74 KB, 1024x1024, img_1791178099833_ao0t9yyu.jpg)ImgOps Exif Google Yandex

>>2266
Check if your event properties are actually being sent with every single event, because Mixpanel won't split them if they only attach to the first one in a session.

84e74 No.2286

File: 1791301746204.jpg (132.28 KB, 1024x1024, img_1791301728628_lm1rvns1.jpg)ImgOps Exif Google Yandex

>>2281
i don't think that's actually why you're seeing one giant bucket though because mixpanel usually carries those properties forward through the session automatically once they are set. if the mapping was truly broken you'd probably see a bunch of null values or empty strings instead of everything just merging together into one group. have you checked if there's some kind of global filter overriding your properties in the report settings?



File: 1790906382604.jpg (241.42 KB, 1024x1024, img_1790906375437_q0mmijqf.jpg)ImgOps Exif Google Yandex

149c0 No.2264[Reply]

i'm seeing totally different conversion numbers between the ui and my sql queries. i tried re-running the attribution reports with the same date range but the session counts won't align. it feels like some of the data is getting dropped during the daily export process. anyone else dealing with this discrepancy lately?

149c0 No.2273

File: 1791072471595.jpg (231.92 KB, 1024x1024, img_1791072456850_1fi09vf5.jpg)ImgOps Exif Google Yandex

>>2264
>it feels like some of the data is getting dropped during the daily export process

check your processing time vs the event timestamp. i've seen cases where queries run before the streaming buffer actually flushes to bigquery, which makes it look like missing rows. this only works if you're looking at recent data from today or yesterday. once the day is finalized and the batch job finishes, that trick won't help much. tbh comparing the event_timestamp to the ingestion time usually clears up the confusion. i use a simple join on the metadata to see what's lagging behind. just don't rely on it for historical audits since those tables are already settled.

149c0 No.2278

File: 1791122366020.jpg (114.62 KB, 1024x1024, img_1791122349930_hvwhenl7.jpg)ImgOps Exif Google Yandex

>>2273
>check your processing time vs the event timestamp
streaming buffer is a nightmare but also check if you're filtering out unassigned sessions in sql while the ui still shows them.

149c0 No.2284

File: 1791286031147.jpg (325.58 KB, 1024x1024, img_1791286012926_xa6cyvrx.jpg)ImgOps Exif Google Yandex

>>2278
>check if you're filtering out unassigned sessions in sql while the ui still shows them
the unassigned stuff is a mess ime. i spent three days last month trying to reconcile a client's revenue because their sql script was stripping out all the 'direct' traffic that lacked a source/medium. google's reporting is basically broken by design if you want everything to match perfectly.
good luck with that



File: 1791262799284.jpg (356.6 KB, 1024x1024, img_1791262791696_6tutr5cg.jpg)ImgOps Exif Google Yandex

76490 No.2283[Reply]

can't even run a proper test without checking impressions first since sessions take way too long to hit significance. it's pretty obvious that tracking things like LLM referrals as secondary data is the only way to see if we're actually moving the needle on ai discovery while the volume is still tiny.
>Impressions are the obvious example: a change that affects rankings, or the range of queries a page shows up for, appears in impressions before it appears in sessions.
it's fine but i don't know how people expect to rely on these noisy metrics when the data is basically just a flat line most weeks. does anyone actually use conversion data as a guardrail for small-scale page tests?

https://www.searchpilot.com/resources/blog/guardrail-metrics


File: 1791220082497.jpg (291.18 KB, 1024x1024, img_1791220072599_i3elxv86.jpg)ImgOps Exif Google Yandex

2ec01 No.2282[Reply]

Google is basically acting like an elephant with our product data.
> Google isn't only working with what you're currently telling it.
It's pulling from old marketplace listings and third-party pages even when the feed is updated correctly. I'm not convinced this isn't just a massive confounder for our recent price testing, especially since we haven't run any long-term audits on those external sites. It's hard to tell if our current discrepancies are actually due to this hidden extra layer or just bad caching.

found this here: https://www.searchenginejournal.com/googles-hidden-data-layer-what-is-it-and-what-to-do-about-it/590234/


File: 1791140609746.jpg (345.6 KB, 1024x1024, img_1791140599817_4973zino.jpg)ImgOps Exif Google Yandex

6aeb2 No.2279[Reply]

The seasonal decline in CrUX makes me doubt any of these recent performance gains. I am not convinced we can separate those trends from Safari 27 fixes or the new INP attribution without a much longer test duration.

link: https://csswizardry.com/2026/07/web-perf-wednesday-002-the-metrics-dont-tell-the-whole-story/


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 ]