Everything we actually build when a company says they want to use Google properly: the full GCP data architecture, clean GA4 collection, BigQuery pipelines, Looker and Looker Studio for reporting, Workspace administration, Apps Script automation, Pub/Sub event topology, identity and security, and how it all connects to the rest of the stack. No hand-waving, no vendor pitch. Just the mechanics and the order we work through them.
This guide is long because the subject is wide. Google Cloud alone covers dozens of services, and Google Workspace is a full productivity and identity platform on top of that. Most teams use a fraction of what they have access to, often badly. What follows is a precise account of how we think about the stack, which parts to reach for first, and how each layer connects to the next. Read it end to end and you will understand how we approach an engagement before we speak.
Google Cloud Platform is not a single product. It is about two hundred services, most of which you will never need. The four that matter most to a growing company are BigQuery (your data warehouse), Cloud Run (containerised workloads without server management), Cloud Functions (small event-triggered code), and Pub/Sub (the messaging layer that ties everything together). Everything else either builds on those or is a specialist need you will know you have when you reach it.
Google Workspace sits separately but connects. It is your email, calendar, documents, and identity provider, and for many teams it is the actual place decisions happen, even when those decisions are technically driven by data sitting in other systems. The integration opportunity is not just connecting Workspace to Cloud; it is making the tools people already use intelligent.
The most common problem we see at audit time is not that the wrong tools were chosen. It is that the right tools were adopted one at a time, without a data model that connects them, so the company has GA4, BigQuery, a CRM, an ad platform, and a product database that have never spoken to each other. The audit exists to find those gaps before the build begins.
The right mental model for a GCP data stack is a funnel: raw data from many sources lands in one warehouse, transformations run inside the warehouse, and reporting tools read from it. BigQuery is the warehouse. It handles petabytes, runs SQL that completes in seconds, and has native connectors to every other GCP service. Choosing it as the central layer is the decision that lets everything else compose cleanly.
The most important decision in the data architecture is the schema. BigQuery is cheap to store and fast to query, but if the schema is a direct dump of application tables it becomes unqueryable by anyone who did not build it. We design schemas around the questions the business actually asks: revenue by channel by day, funnel conversion by cohort, churn by product tier. The tables are wide on purpose, and the transformations are written in standard SQL that your team can read and verify.
ELT stands for extract, load, transform. The data arrives raw in BigQuery first, then transformations run inside the warehouse using SQL or a tool like dbt. This is the opposite of the older ETL pattern where you transformed before loading, and it is better for two reasons: the raw data is always there if you need to reprocess it, and BigQuery is faster and cheaper at running transforms than any external service.
The practical work of building an ELT pipeline has four phases. First, inventory the sources: what data exists, where it lives, how it is accessed (API, webhook, file export, database replica), and at what latency you need it. Second, design the raw schema to preserve the source structure faithfully, including fields you do not currently use. Third, build the extraction layer, handling authentication, pagination, and rate limiting properly. Fourth, write the transformations that produce the business-facing tables.
The pipelines we most commonly build connect Salesforce or HubSpot (via REST API with incremental loads), Google Ads and Meta Ads (via their respective APIs), Stripe (via webhooks into Pub/Sub), and the product database (via a read replica or a CDC stream). Each runs independently, so a failure in one source does not break the others, and each one is monitored with alerting on the raw table's last-updated timestamp.
GA4 is the right analytics platform for most growing companies, but the default client-side setup has a structural problem: the measurement code runs in the user's browser, which means ad blockers, iOS Intelligent Tracking Prevention, and cookie consent banners all erode your data before it reaches Google. Studies across typical e-commerce and SaaS properties consistently show 20 to 40 percent of sessions go untracked on a client-side-only setup.
Server-side tagging fixes this by moving the collection endpoint to a container you control, running on Cloud Run. The browser sends events to your own domain, not directly to Google. Your server-side container then forwards them to GA4 and any other destinations (Google Ads, Meta, CRM webhooks). The benefits are concrete: better data completeness, first-party cookies that survive ITP, and no PII leaving your infrastructure before you have had a chance to hash or strip it.
The setup has three parts: a Google Tag Manager web container that fires to your sGTM endpoint instead of directly to GA4, a server-side GTM container hosted on Cloud Run with auto-scaling configured, and the GA4 and advertising tags rebuilt on the server side with proper variable mapping. The Cloud Run configuration needs a custom subdomain pointing to it so the cookies set are first-party; without that, the ITP benefit disappears.
We also connect GA4's BigQuery export. Every event GA4 records gets streamed daily (or in real time on the 360 tier) into a BigQuery dataset. That raw events table is the foundation of the analytics work: you can query it with SQL, join it to your product database, and build custom funnels that GA4's own interface does not support. It is one of the few free integrations in the Google stack that pays back immediately.
Looker Studio (formerly Data Studio) is the right tool for most reporting needs. It connects directly to BigQuery, refreshes on a schedule, and produces dashboards that non-technical teams can read and share without touching SQL. The key to a Looker Studio setup that actually gets used is connecting it to clean, well-named BigQuery tables rather than raw source data, so the metrics are consistent across every report.
Looker (the full enterprise product, now part of Google Cloud) adds a semantic layer: a set of metric definitions that sit between the data and the reporting tools, ensuring that "revenue" means the same thing whether you query it in Looker, from a Python notebook, or via the REST API. For teams where consistent metric definitions across multiple tools is a real problem, the semantic layer is worth the investment. For teams at an earlier stage, Looker Studio directly on BigQuery is faster to ship and cheaper to run.
The dashboards we build follow a consistent pattern: one executive overview covering the four or five numbers that actually drive decisions (revenue, pipeline, activation, churn, spend efficiency), and one operational dashboard per team (marketing funnel by channel, product activation by cohort, customer health by tier). Every chart has a SQL query you can read, and every metric has a written definition that appears on hover. The goal is that anyone looking at the dashboard can understand what they are seeing without asking the analyst who built it.
Pub/Sub is the messaging backbone that makes GCP composable. Instead of services calling each other directly, a producer publishes an event to a topic and any number of subscribers act on it independently. A new customer signs up in your product: one subscriber loads the event to BigQuery, another triggers a welcome sequence in your CRM, a third updates a counter in a Sheets dashboard. None of them know about each other, and if one fails, it retries without affecting the others.
We use Pub/Sub for three categories of event. The first is data pipeline triggers: a webhook from Stripe or a product event fires a Pub/Sub message, which triggers the Cloud Function that loads it to BigQuery. The second is cross-system syncs: a deal closed in the CRM publishes an event that triggers a Customer Success task, a Looker Studio refresh, and an invoice draft, all at once, none of them blocking each other. The third is monitoring and alerting: a BigQuery scheduled query publishes to a topic when a key metric crosses a threshold, and a subscriber routes the alert to Slack or email.
Workspace is often the last thing a growing company thinks about until it becomes a problem: a user account that was not deprovisioned after someone left, a Shared Drive that has no owner and three thousand files nobody can find, a security alert that fired months ago and nobody saw. Good Workspace administration is not glamorous, but it is the foundation that everything else in the Google stack sits on, because Workspace is the identity provider.
The administration work we do covers five areas. User lifecycle management: provisioning new accounts with the right groups and permissions from day one, and deprovisioning leavers completely including revoking third-party OAuth tokens. Shared Drive governance: auditing who owns what, applying retention and deletion policies, and moving orphaned content to managed locations. Security baseline: enforcing two-factor authentication across the whole organisation, reviewing admin account inventory, and configuring the Security Investigation Tool to surface unusual activity. Licence management: matching licence tiers to actual usage so you are not paying for features nobody uses. And compliance configuration: setting data regions, configuring Vault for legal hold if needed, and reviewing third-party app permissions.
The audit surfaces all of these. Most organisations we work with have at least two or three accounts that should have been deprovisioned but were not, at least one admin account that is not enrolled in two-factor authentication, and at least a dozen third-party app authorisations that nobody remembers approving.
Apps Script is Google's built-in automation layer for Workspace. It runs JavaScript in Google's infrastructure, has direct access to Sheets, Docs, Drive, Gmail, Calendar, and Forms without any authentication overhead, and can call external APIs. It is not a general-purpose programming environment, but for the specific category of automating Workspace workflows, it is faster and cheaper to build with than any external tool.
The automations we most commonly build with Apps Script fall into four groups. Form processing: a Google Form collects data, the script validates it, writes a row to a Sheet, sends confirmation emails, creates calendar invites, and optionally posts to Slack or a CRM. Document generation: a script reads data from a Sheet or BigQuery, fills a Docs template, and saves the output to a named Drive folder, replacing a process that used to take someone an afternoon. Approval workflows: a script routes a Sheet row through an approval chain via email, updating status as each approver acts. And data syncs: lightweight scheduled scripts that push Sheets data to an external API or pull data back, for systems where a full pipeline would be overkill.
Identity is the one area where a mistake is hard to recover from. A misconfigured IAM role that grants a service account project-owner access, a Workspace admin account without two-factor authentication, or an OAuth token left on a departed employee's account are all attack surfaces that compound over time. We treat identity and IAM as a first-class deliverable, not an afterthought.
On the GCP side, the principle of least privilege is the rule. Every service account gets exactly the permissions it needs for the specific resources it touches, written as a custom IAM role, not a predefined role at the project level. Service account keys are not used where Workload Identity Federation or the metadata service can provide credentials instead; keys that cannot be avoided are rotated on a schedule. Access to BigQuery datasets is controlled at the dataset and table level, not at the project level, so a developer can query clean tables without touching raw data or other teams' datasets.
On the Workspace side, the admin console security recommendations are a floor, not a ceiling. Beyond enforcing two-factor authentication and reviewing admin accounts, we configure context-aware access policies for any Workspace app that handles sensitive data, review and trim the third-party OAuth app authorisations that accumulate silently over years, and set up the Security Investigation Tool to alert on suspicious sign-in activity, bulk Drive downloads, and external sharing of sensitive documents.
Google Cloud connects to external systems through two patterns. The first is pull: a Cloud Function or scheduled query calls an external API on a schedule, fetches data, and loads it to BigQuery. This covers most reporting use cases: your CRM, your ad platforms, your billing system. The second is push: an external system calls a Cloud endpoint (usually a Cloud Function behind a Cloud Endpoints or API Gateway configuration, or a Pub/Sub push subscription) when something changes. This covers real-time triggers: a payment completes, a user activates, a deal closes.
The integrations we build most frequently are CRM sync (Salesforce and HubSpot both have well-documented REST APIs with incremental load support), advertising platforms (Google Ads, Meta, LinkedIn all have APIs that return campaign and conversion data with a two-day lag), payment processors (Stripe's webhook system is reliable and its event model maps cleanly to Pub/Sub), and product databases (typically via a read replica or a Fivetran or Airbyte connector if one is already in place). We document each integration in a standard format: the API endpoint, the authentication method, the fields extracted, the schedule, and the failure behaviour.
Every engagement opens with the free audit, which produces a prioritised list of what to build and in what order. The build itself is a fixed-scope project, structured in two to three phases depending on the complexity of the stack.
Phase one is always the foundation: GA4 server-side tagging, BigQuery connected to GA4 export, IAM baseline on GCP, Workspace security hardening. This is the work that makes everything else reliable. Phase two is the data layer: ELT pipelines for the two or three source systems that matter most, the BigQuery schema that joins them, and the first Looker Studio dashboards. Phase three, where needed, covers automation: Pub/Sub topology for event-driven integrations, Apps Script automations for the highest-value manual workflows, and Workspace administration for teams with significant lifecycle management needs.
Everything we build is documented to a standard that lets your team own it after handover. Each pipeline has a runbook describing what it does, how it is monitored, and how to restart it if it fails. Each dashboard has a data dictionary that defines every metric. Each Apps Script automation has inline comments and a test Sheet that lets you trigger it manually. The goal is that six months after we hand over, your team can maintain and extend the work without coming back to us.
One point of contact. You get one person who owns the engagement, the delivery schedule, and any escalation. Specifications arrive in a standard format with acceptance criteria your team can check. The starting datasets and reports are yours to keep, and the code is deployed to your own GCP project, not ours.
That is the full architecture. When you want it applied to your stack, the next step is a free audit: a real review of your GCP and Workspace environment, findings in a week, no obligation.
A free audit of your real Google stack, the findings quantified, and a fixed scope to build what is missing. Findings in a week.
Get a free Google audit