How to Automate Strava to Google Sheets with Make

What the Strava to Google Sheets workflow should do

The intended business state is straightforward: when a new Strava activity is available, one corresponding record should appear in Google Sheets. The record should contain enough information to identify the activity and analyze it later, but not so many fields that the sheet becomes difficult to maintain.

For this workflow, define one row as one Strava activity. That decision affects every later step, including duplicate handling, formulas, summaries and troubleshooting. If one row sometimes represents an activity and sometimes represents a weekly total, reporting will become difficult to interpret.

Prepare the Google Sheet before building the scenario

Create the spreadsheet and add a single header row before configuring Make. Use descriptive, stable column names so the mapping remains understandable when the scenario is revisited later.

A practical starting structure might include:

• Activity ID: a unique identifier where the trigger provides one.
• Start date: the activity start date and time.
• Activity name: the name assigned in Strava.
• Activity type: such as run, ride or swim.
• Distance: the distance value and, if needed, a separate unit convention.
• Moving time: active duration.
• Elapsed time: total duration.
• Average speed or pace: choose the field that matches your reporting needs.
• Source: a fixed value such as Strava, if the sheet may later receive other data.

Keep calculated fields separate from imported fields. For example, a weekly grouping formula or a converted distance should not overwrite the value received from Strava. This makes it easier to identify whether an error came from the source data, the Make mapping or a spreadsheet formula.

Build the Make scenario

In Make, create a new scenario and add Strava as the first module. Select the event that watches for new activities. The exact module label and available options may vary as the connector changes, so choose the trigger that represents a newly available activity rather than an action that updates an existing record.

1. Open Make and create a new scenario.
2. Add the Strava app as the first module.
3. Select the new-activity trigger available in your account.
4. Create or select the Strava connection and complete the authorization prompts.
5. Review any starting point, activity type or retrieval settings offered by the trigger.

Then add Google Sheets as the next module and choose the action that adds a row. Select the spreadsheet file and the worksheet tab containing your headers. Make should expose the destination columns so values from the Strava module can be mapped into them.

At this stage, resist the temptation to add notifications, dashboards or extra transformations. First prove that the core path works: one valid Strava activity becomes one understandable spreadsheet row.

Map Strava data to the right columns

Mapping is the point at which the scenario becomes a data model rather than a simple connection. Click each Google Sheets field and select the corresponding value from the Strava output.

• Map the activity identifier to Activity ID if it is available.
• Map the activity start timestamp to Start date.
• Map the source activity name and type to their matching columns.
• Map distance, moving time and elapsed time to separate fields.
• Map average speed or pace according to the way you plan to report performance.
• Use a fixed source value if the sheet may later combine activities from multiple systems.

Do not assume that similarly named fields have the same meaning. Moving time and elapsed time can differ. Speed and pace are also different measures, even when both appear to describe performance. Choose the field based on the question the report must answer.

If the scenario exposes nested values or multiple representations of a field, inspect the test bundle before choosing one. A field that looks correct in the mapping panel may still need a date format, unit conversion or spreadsheet formula to display properly.

Test the scenario before scheduling it

Use Make’s test or run-once function to inspect the complete path. The aim is not only to confirm that a row appears. You also need to verify that the row has the expected meaning.

1. Start a test run in Make.
2. Provide a new or available Strava activity according to the trigger’s behavior.
3. Inspect the data received by the Strava module.
4. Inspect the values sent to the Google Sheets module.
5. Open the sheet and check dates, units, durations and text fields.
6. Confirm that one activity produced one row.

Test with realistic variation where possible. A run, ride or other activity may expose different fields. Empty optional values should not shift data into the wrong column. If a field is not available for every activity type, decide whether the destination should remain blank or use a separate transformation.

Prevent duplicate and unclear records

Duplicate prevention deserves attention because scheduled workflows can encounter retries, repeated polling or changes to the way a trigger identifies new items. If the Strava output includes a stable activity ID, keep it in the sheet and use it as the record’s reference.

Before adding filters or extra modules, define the decision rule:

1. New activity with no matching ID: add a row.
2. Activity ID already present: do not create another row.
3. Existing activity has changed: decide whether to update the row or preserve the original record.
4. No stable identifier is available: document the fallback matching rule and accept that it may require manual review.

The simplest initial version may only add rows. If duplicate risk becomes material, add a lookup and a clear route for existing records. Do not build that complexity before understanding how the trigger behaves in practice.

Schedule and monitor the scenario

Once the test is correct, configure the scenario schedule to match the required freshness of the sheet. A personal training log may not need immediate updates. A report used shortly after an activity may need more frequent polling. The right schedule is determined by the decision that depends on the data, not by a preference for maximum frequency.

Turn the scenario on after the schedule is configured. Review the execution history after the first few scheduled runs and whenever you change the spreadsheet headers, trigger settings or mapping. A sheet can look current while missing activities, duplicating rows or receiving malformed values.

Useful reporting without overbuilding

Once the raw activity log is reliable, add reporting that answers a defined question. Examples include distance by week, activity count by type, total moving time or a comparison of planned and completed sessions if that data exists elsewhere.

Keep summary formulas and pivot tables separate from the imported table where practical. This protects the raw record and makes it easier to change the reporting view without changing the automation. If the sheet becomes difficult to audit, the next step may be a more structured data system rather than more formulas.

The same process-first approach applies when this small workflow becomes part of a wider operating system. ConsultEvo’s systems and automation services can be relevant when integrations, ownership and reporting need to be designed together. ConsultEvo also shares examples of connected automation, CRM and operations systems where the workflow is designed around an operational need rather than a collection of disconnected tools.

Operational observations

A spreadsheet becomes a system of record only when each row has a stable meaning and a reliable identifier.

Schedule frequency should follow the decision supported by the data, not the maximum frequency the tool allows.

Imported values and reporting logic should remain separate so data corrections do not destroy the original record.

Adding more modules does not improve an automation until the trigger, ownership and desired business state are clear.