Abstract navy cover with linked data and the guide “How to Combine Multiple Data Sources in Google Sheets”.

This article contains affiliate links. AutomateWithMNK may earn a commission if you sign up through certain links, at no additional cost to you. This does not influence our editorial assessment.

Combining sources in Google Sheets starts with the meaning of the final row. Stacking comparable observations and enriching them with a reference table are different operations. Coupler.io supplies preparation mechanisms, while your model establishes whether the records belong together.

This documentary guide uses two fictional campaign-spend datasets and an owner reference. It retains source context, checks row counts after enrichment and avoids inventing customer attribution from a shared campaign name.

Disclosure: this article includes a Coupler.io affiliate link. We may earn a commission if you purchase through that link.

Documentary analysis dated 14 October 2026, without a product account test. Numerical examples are fictional and illustrate the method.

Define the final observation

The fictional company Juniper wants one row per day, platform, account and campaign. That identity lets two unrelated campaigns share a display name without becoming one record. Friendly names are useful labels, not automatically reliable keys.

The first and second datasets hold observations from different platforms. A third table provides an owner for an account-campaign combination. That reference is not another spend series and should not be stacked into the observation table.

Write the final dictionary before connecting sources: day, platform, account, campaign, currency, spend and owner. Decide what happens when a required identifier is missing or a responsible person is unknown. Keeping an exception visible is often more useful than deleting the row to make the report look complete.

Normalise a small sample before combining it

Fictional observations after normalisation
DayPlatformAccountCampaignSpend GBP
2026-10-12Platform AJA-1C-2170
2026-10-12Platform BJB-2C-2150
2026-10-13Platform AJA-1C-2190

The illustrative total is 210 GBP. The two C-21 campaigns remain distinct because their account and platform context is retained. This is a proposed data model, not an observed product result.

Choose stacking or enrichment deliberately

Coupler.io’s transformation overview distinguishes combining similarly structured datasets from adding context through matching fields. Juniper first stacks compatible observations, then enriches them from its owner reference.

Before stacking, inspect units, types and definitions. A spend column may carry a normal currency amount in one dataset and a technical unit in another. Conversion fields may also describe different events. Similar headings do not establish compatible measures.

Before joining, define the expected relationship. If one campaign has two reference rows, enrichment may multiply observations. That can be a modelling issue rather than a product defect. Establish whether each observation is supposed to match one reference record, several records or none.

Configure and check each source independently

The official Coupler.io tutorial documents adding sources and preparing data. Authorise each source, select the useful scope and inspect its preview separately before combining the outputs.

Juniper first locates the 70 GBP observation in platform A and the 50 GBP observation in platform B. It checks dates and currency as well as amount. A correct combined total can conceal compensating errors, so individual traceability remains necessary.

Rename fields towards the final dictionary while retaining original identifiers. Add platform or account context when a bare identifier is not globally unique. Do not apply one conversion rule across every source until you have shown it is appropriate for each. Save the mapping with the report so another maintainer can repeat that reasoning.

Combine and inspect the relationship size

Stacking the compatible observations should produce the three sample rows and retain the 210 GBP total. If the amount changes, examine unit conversion, periods and repeated records before adding more sources.

The reference maps platform A, JA-1, C-21 to Morgan and platform B, JB-2, C-21 to Sam. Use the matching columns that preserve this context in your configuration. A join on the campaign label alone would be insufficient for this example.

After enrichment, compare row counts and distinct observation keys with the pre-join dataset. A many-observations-to-one-owner relationship should not multiply the spend records. If rows disappear or expand unexpectedly, inspect the matches before aggregating. The enriched table’s appearance is not evidence that its total remains valid.

Reproduce the model with three working tabs

Prepare an authorised source workbook with observations_a, observations_b and owners. The first two hold the sample observations. The reference has campaign_key and owner columns. Add campaign_key to observations: A|JA-1|C-21 for platform A and B|JB-2|C-21 for platform B. In the reference, those keys map to Morgan and Sam. This composite key is a proposed upstream data model, not an identifier automatically supplied by Coupler.io.

Create a flow with Google Sheets as a source, use Connect and select the file and tab. The Google Sheets source guide describes account authorisation and range selection. Use first-row headings and A:Z for the small sample. Add the two observation datasets and the reference separately so their structures can be inspected.

Stack observations before enriching them

Use Append for the compatible observation datasets, retaining platform, account and campaign_key. For enrichment, select Join data with observations on the left and the reference on the right, matching campaign_key. The official tutorial describes keeping left-hand records and adding matching right-hand information. Before writing to the destination, expect three observations, three distinct day-campaign_key identities and the unchanged 210 GBP total. Several owner matches for a key require review of the reference.

The source help page still uses some older plan names in its row-limit discussion. Do not treat those as the current offer: consult the live pricing grid for allowed volume. This small example establishes the documented mechanism and acceptance cases, not a guaranteed volume entitlement.

Check the cases that expose an unreliable model

Juniper reconciliation cases
CaseExpected resultResponse
C-21 on two platformsDistinct identitiesKeep account and platform context
Two owners for JA-1/C-21Visible ambiguityResolve the reference mapping
Missing ownerObservation retained and flaggedAssign a human review
USD spend addedCurrency kept separateDefine conversion or a separate view
Repeated full-period extractionNo invented extra spendInspect writing mode and observation identity

Write to Sheets without conflating two append decisions

Configure a dedicated Google Sheets destination according to the documented procedure. Keep commentary and formulas outside the area the flow owns. Manual annotations should not be silently overwritten by the next refresh.

If every run retrieves the same complete scope, the destination should not simply accumulate repeated copies. Appending sources during preparation and appending rows to the destination are separate decisions. Their similar names can conceal different effects.

Run manually and reconcile the amount before and after writing. Check numerical formats, workbook locale and visible dates. A number imported as text can look reasonable while being excluded from the expected calculation. The final workbook, not just the preparation preview, needs acceptance.

Align periods and explain partial freshness

A combined table can contain sources extracted at different times. Retain observation periods and source extraction information where your reporting design provides it. The reader should know whether every component covers the same window.

Use the documented refresh settings only after the model reconciles. Select a cadence supported by the sources and plan, then review what happens when one source is unavailable. A partially updated report needs to be recognisable as partial.

For monthly delivery, agree a closing date and revision policy. A platform may later revise an earlier day, so adding only new observations can miss the change. The refresh model must account for revisions as well as new records. Keep the delivered report copy if decisions depend on what was visible at the time.

Keep each value’s authority identifiable

Juniper corrects owner mappings in its reference and source measures through the relevant business system. The report does not become a second competing authority. The dictionary identifies where each field should be maintained.

Our HubSpot and Make contact-identity guide explains a different setting where identifiers and events must remain distinct. Here, observation keys serve analytical reconciliation rather than creating new commercial records.

When a third dataset is added, repeat the definition and row-grain checks. A larger connector inventory is not the same as a trustworthy combined total. A traceable model can grow; a total whose origins no longer reconcile is difficult to defend during a business decision.

FAQ : practical questions

What is the difference between Append and Join here?

Stacking adds compatible observations vertically; joining enriches observations through a matching relationship. Choose from the data structure and expected relationship, not the similar appearance of the tables.

Why did a join increase the total?

There may be several reference matches for one observation. Inspect the matching keys and relationship size before aggregation. A campaign display name may not be a sufficient identity.

Should campaigns with the same name be merged?

Not automatically. Different platforms or accounts can reuse a name. Preserve context and establish a shared identity only when the business definition supports it.

Does combining sources deduplicate attributed sales?

No. Technical combination does not establish customer identity or an attribution method. Keep platform measures separate until that method is defined.

Choose your next step

Define the final observation and key, then reconcile two small sources and a filled reference table. Accept totals and exceptions before scheduling the flow. If Coupler.io covers the sources and preparation needed, review its offer through the approved affiliate link.

Explore Coupler.io for combining your reporting sources

Official sources

Checked on 14 October 2026.