u/PakiusNpe

If you’re using tools like Supermetrics, Funnel, Windsor (or similar) to pull data from Meta / TikTok / Google Ads into Sheets, dashboards, or warehouses:

What still doesn’t work properly in day-to-day use?

I’m trying to understand what’s still painful once these tools are already in place not the marketing claims, but the operational reality.

For example:

• Is setup still more painful than expected?
• Do connectors randomly break or require babysitting?
• Is data consistency still an issue (missing fields, mismatched numbers, delays)?
• Is pricing annoying/unpredictable once you scale?
• Do you actually trust the numbers when reporting to clients/management?
• Or is the real pain somewhere else entirely (workflow, reporting overload, constant fixes, etc.)?

Curious what’s actually still frustrating in practice for people using these tools regularly.

If you’re using tools like Supermetrics, Funnel, Windsor (or similar) to pull data from Meta / TikTok / Google Ads into Sheets, dashboards, or warehouses:

What still doesn’t work properly in real life?

I’m trying to understand what’s still painful once these tools are already in place, not the marketing claims, but day-to-day usage.

For example:

• Is setup still more painful than expected?
• Do connectors randomly break or require babysitting?
• Is data consistency still an issue (missing fields, mismatched numbers, delays)?
• Is pricing annoying/unpredictable once you scale?
• Do you actually trust the numbers when reporting to clients/management?
• Or is the real pain somewhere else entirely (workflow, reporting overload, constant fixes, etc.)?

It feels like these tools are widely used, but I also keep hearing that teams still spend a lot of time "fixing data" instead of using it.

Curious what’s actually still frustrating in practice for people using them regularly.

I’m a Go engineer and I’ve been looking at how teams structure small data sync / ingestion jobs that run repeatedly over time.

Typical pattern in my case (and in systems I’ve worked with):

- Go scripts pulling data from external APIs (Stripe, HubSpot, internal services, etc.)

- some lightweight transformation

- writing into Postgres / S3 / warehouse tables

- executed via cron, CI pipelines, or simple schedulers

What I keep noticing is that once these jobs need to run repeatedly, the “hard part” becomes consistency over time rather than the actual API calls.

Specifically:

1. Incremental loading / avoiding full re-syncs

- using updated_at timestamps

- storing cursors or “last processed id”

- sometimes full re-fetch + deduplication downstream

2. State tracking

- DB table storing last successful sync point

- local file-based state

- or implicit state derived from queries

3. Failure + resume behavior

- full job reruns on failure

- partial retries per batch

- sometimes manual recovery steps when things break mid-run

What I’m trying to understand is:

- Is this just the normal way Go ingestion jobs are built in production?

- Or do teams usually converge on a shared pattern or internal library for handling incremental sync + state + retries?

- At what point does this become something you standardize vs just keep per-job logic?

Curious how others handle this in real systems especially if you’ve had to scale beyond a handful of these jobs.