Marketing from the command line

Marketing from the command line is running your audiences, personalization, and journeys as text commands that pipe together, so a campaign becomes something you can script, review, and reproduce like any other code.

The trailguide CLI is built for exactly that. It is pipe-friendly and scriptable, it reads from any data source, and it deploys live journeys straight from your terminal or your CI pipeline. For developers and ops teams, it is the marketing-as-code interface that sits next to the plain-language MCP tools and the web app.

One pipe from warehouse to a live journey

The clearest way to see it is a single line. Extract from your production database, personalize with a strategy, and deploy the result as a live journey, all in one pipe:

trailguide extract postgres://prod | personalize --strategy similar | journey deploy

Each stage does one job and hands its output to the next. extract pulls rows from a source. personalize picks a next action for each member, here using a similar-audience strategy. journey deploy makes the result live. Because the stages compose, you can insert a filter, swap the strategy, or send the middle of the pipe to a file and inspect it before anything ships.

Marketing becomes reviewable in pull requests

When a campaign is text, it lives in your repository like everything else you build. A change to an audience or a journey shows up as a diff. A teammate reviews it, comments on a line, and approves it before it merges. The record of who changed what, and why, is your commit history.

That is a real shift from clicking through a console where the only trace is an audit log after the fact. Marketing as code means the review habits your engineers already have now apply to lifecycle marketing:

• Diffs: every audience and journey change is visible line by line.
• Review: approval happens in the pull request, before anything goes live.
• History: your version control is the record of what shipped and when.

The same commands run in CI

Because the CLI is just text in and text out, it drops into a pipeline without special handling. A merge to your main branch can run the same pipe your marketer ran locally, so what you reviewed is exactly what deploys.

# on merge to main, in CI
trailguide extract postgres://prod | personalize --strategy similar | journey deploy --confirm

Runs are reproducible: the same input and the same command produce the same journey every time. Nothing depends on remembering which buttons someone clicked last week, and a rollback is just re-running an earlier revision of the same script.

It composes with tools you already have

Because every stage is plain text, the CLI composes with the tools already on your machine. Filter members with grep, reshape a payload with jq, gate a deploy behind a test, or schedule the whole pipe with cron. TrailGuide does not ask you to leave the toolbox you know, because it becomes one more command inside it.

That composability is the practical payoff of marketing as code. A campaign is not trapped in a vendor console. It is a script you can read, version, wrap in your own checks, and hand to a teammate or an agent to run the same way every time. The console is optional; the script is the source of truth.

Where the CLI fits

The command line does not replace the other interfaces. It is one of three doors into the same orchestration layer: plain-language MCP for anyone on the team, the web app for a visual view, and the CLI for developers who want journeys that behave like code. Pick the door that fits the task, because the system underneath is identical.

It also reads from the same places everything else does. The extract stage speaks to any data source you already run, so the command line is not a limited side channel. It is the full harness, addressed as text.