GA4 to Iceberg: land Google Analytics 4 reports in your own AWS account

GA4 to Iceberg on AWS through OptimaFlo means the same setup as any GA4 connection: a service account with Viewer access on your property, a report definition (dimensions, metrics, lookback window), except the result lands as an Apache Iceberg table in your own AWS account, with no GCP project required to receive it. Service account setup and property sharing take about 20 to 30 minutes the first time; report configuration is a few minutes after that.

How the connector actually talks to GA4

This is the Google Analytics Data API (analyticsdata.googleapis.com), called directly with httpx and a minted bearer token, not the google-analytics-data SDK and not GA4's native BigQuery export linking. It hits two endpoints: a metadata endpoint that returns the full catalog of dimensions and metrics available on your property, and runReport, which returns report rows for the dimensions, metrics, and date range you configured. Because GA4 caps a single runReport response at 250,000 rows, the connector pages through limit/offset automatically until a page comes back short, or until an explicit row cap (used for previews) is reached. None of this depends on which cloud your OptimaFlo BYOC deployment runs in, GA4 is a Google API either way, the destination for the rows is what changes.

Auth is service-account only, on purpose

v1 of this connector requires service_account_json, a JSON dict, JSON string, or file path, and validation fails before a connector object is even created if it is missing. There is deliberately no Application Default Credentials fallback: if there were, OptimaFlo's own platform identity could stand in for a customer's GA4 access, which is not what you want when the whole point of BYOC is that your data and your access stay yours. You share the GA4 property with the service account's email address, the same flow regardless of whether your Iceberg tables land in GCS or S3.

Schema validation against the live catalog

Every configured dimension and metric name is checked against your property's actual metadata catalog before the first row is fetched. A dimension you typed wrong, or a metric that does not exist on this property, raises a clear error naming the bad field, rather than silently ingesting a report with a missing column. GA4's own metric types (TYPE_INTEGER, TYPE_FLOAT, and others) map to a coarse integer/float/string schema; unmapped types stay string, which matches the API's own wire format (runReport returns every value as a string regardless of its declared type).

If you still want a warehouse on top

Landing in Iceberg does not close off Snowflake or a database as a downstream target. Once the report data has gone through Clean and Ready modeling, the same destination export every other connector uses can push a Gold table to Snowflake, Postgres, or MySQL, in append, overwrite, or upsert mode. BigQuery is the one exception here: it needs a GCP project to land in, so it is only reachable if you also run or provision a GCP destination.

What is not supported

No real-time or streaming GA4 data (this is the standard reporting API, with its usual data-processing latency), no BigQuery-export-linked ingestion path, and no ADC fallback if you would rather skip service account key management. The 90-day default lookback is configurable up to about ten years, but every run re-requests the full configured window; there is no incremental "only fetch new dates" behavior built in yet.