All use cases

Campaign-to-Pipeline Attribution

Sync Google Ads spend and HubSpot campaign engagement into BigQuery on a schedule so marketing and sales report from the same pipeline numbers.
Google AdsHubSpotGoogle BigQuery

The problem

Marketing reports from the ad platforms, sales reports from the CRM, and the numbers rarely agree. Analysts export spend and engagement by hand into spreadsheets or the warehouse, so attribution is always days behind. Nobody trusts the pipeline number in the Monday meeting.

How it runs on Neblex

A cron schedule pulls spend and performance from Google Ads at whatever cadence you choose. Poll-based change detection watches HubSpot campaigns and contacts, catching inserts, updates, and deletes through cursors and content hashing, so removed or renamed campaigns do not linger in your reporting.

Transforms and field mapping shape both sources into a common model, and chunked batch processing with checkpoints loads the data into Google BigQuery. Because every SQL database connector runs arbitrary SQL, the flow runs the join and attribution queries in BigQuery as a step, then writes summarized attribution back to HubSpot.

If a load fails partway, the run resumes from its last checkpoint instead of starting over, and a failed run can be replayed from the exact step that broke. Bulk replay recovers up to 200 failed runs at once after a fix.

Step by step

  1. Pull ad spendA cron schedule fetches Google Ads spend and performance for the reporting window.
  2. Detect CRM changesPoll-based change detection picks up new, updated, and deleted HubSpot campaigns and engagements.
  3. Transform to one modelTransforms and field mapping align both sources on shared campaign and contact keys.
  4. Load into BigQueryChunked batches with checkpoints write the data, so partial failures resume cleanly.
  5. Compute attribution in SQLAn arbitrary SQL step runs the attribution queries directly in BigQuery.
  6. Write back to HubSpotSummarized attribution lands on campaigns so marketing and sales read the same numbers.

Platform capabilities used

  • Cron schedules
  • Poll-based change detection
  • Chunked batch processing with checkpoints
  • Arbitrary SQL on database connectors
  • Transforms and field mapping
  • Bulk replay

Common questions

How are deleted or renamed campaigns handled?

Poll-based change detection uses cursors and content hashing, so it sees deletes and updates as well as inserts. The flow can mark removed campaigns in BigQuery instead of leaving stale rows behind.

What happens if a nightly load fails?

Chunked batch processing records checkpoints, and a failed run replays from the exact step that broke. You fix the cause and replay, rather than rebuilding the table by hand.

Can we rerun history after changing the mapping?

Failed runs, yes: bulk replay recovers up to 200 at once, each from the step that failed. To reload a window that already succeeded, run the load again for that date range; the merge on the record key keeps it from duplicating rows.

Want this running on your stack?

Neblex Integration Fabric is generally available: every core feature on every plan. Bring this workflow and we will map it to your systems.