A well-built marketing data mart is worthless if the people who need it can't reach it. Most marketers, campaign managers, and even many analysts don't write SQL fluently, and shouldn't need to for routine work — asking every list pull to go through a data analyst creates a queue, and queues kill campaign velocity. The access and delivery layer is the set of tools and patterns that let marketing self-serve data without either writing raw queries or waiting in line behind engineering.

Self-service BI tools

Tools like Looker, Tableau, Power BI, and Mode sit on top of the warehouse and expose pre-modeled metrics and dimensions through a drag-and-drop interface. A marketer builds a filter — lifecycle stage equals 'active', last purchase category equals 'apparel' — and the tool generates the SQL behind the scenes. This works well for exploration and reporting, and increasingly for campaign list-building when the BI tool supports exporting a filtered result set directly to an ESP or ad platform audience.

The quality of self-service BI is entirely downstream of the semantic layer underneath it (covered in the next module) — a BI tool pointed at a messy, undocumented warehouse just lets marketers self-serve their way into wrong numbers faster.

Scheduled extracts

The oldest and still most common delivery pattern: a scheduled job runs a defined query against the mart and drops the result as a file (CSV, often) into a location the campaign tool can pick up — an SFTP folder, a cloud storage bucket, or a direct import into the ESP. This is batch-oriented, low-maintenance once set up, and remains the backbone of most list-based email and direct mail campaigns.

Its weakness is rigidity: changing the logic of an extract means someone has to edit the underlying query, and marketers can't adjust targeting criteria themselves without going back to whoever owns the extract.

API access

Increasingly, marketing platforms (CDPs, ESPs, ad platforms) expose APIs that pull segment membership or customer attributes on demand rather than via a static file drop. This enables near-real-time use cases — an ad platform's audience API refreshing a retargeting list every few minutes, a personalization engine calling a customer-attributes API at the moment a page renders. API access requires more engineering investment up front (authentication, rate limiting, error handling) but removes the batch-file latency entirely.

data_access_layers.txt

text

Marketing Data Mart
       |
       |----> Self-service BI (Looker/Tableau) ----> Marketer builds own filter, exports audience
       |
       |----> Scheduled extract (SQL -> CSV -> SFTP/S3) ----> ESP batch import
       |
       |----> API endpoint (REST/GraphQL) ----> Ad platform / personalization engine, near-real-time pull

Flexibility vs. governance across access methods

Access method	Marketer flexibility	Governance risk	Typical use case
Self-service BI	High — build own filters	Medium — depends on semantic layer quality	Ad hoc segment building, reporting
Scheduled extract	Low — fixed logic, edited by data team	Low — centrally controlled	Recurring list-based campaigns
Direct SQL access	Highest — full query freedom	Highest — no guardrails on logic or PII	Analyst-built one-off pulls
API access	Medium — constrained by endpoint design	Medium — access controlled by auth scope	Real-time personalization, ad audience sync

The flexibility/governance tradeoff is the whole design problem

Every access method trades flexibility for control. Give marketers direct SQL access and you get maximum speed but zero consistency — two marketers can define "active customer" two different ways in the same week. Lock everything behind data-team-owned extracts and you get consistency but a request queue that makes marketing dependent on another team's sprint capacity. The right answer is usually layered: a governed semantic layer underneath self-service BI, so marketers get flexibility constrained to definitions the business has already agreed on.

PII exposure scales with access breadth

Self-service and API access both widen the surface area for PII exposure compared to a centrally-reviewed extract. Row-level security, field masking (hashing emails for matching without exposing raw addresses), and audience-size minimums before export are standard guardrails — and they need to be built into the access layer itself, not left to each marketer's judgment.

Choosing the right method per use case

Most mature marketing orgs run all three patterns simultaneously, matched to the use case: scheduled extracts for stable recurring campaigns, self-service BI for ad hoc segment exploration and reporting, and API access for the handful of real-time, high-value triggers. The mistake is picking one pattern and forcing every use case through it — a real-time personalization need forced through a nightly extract arrives a day late, while routing every recurring weekly newsletter segment through an engineer-built API is needless overhead.

What's next

None of these access methods work well without a shared vocabulary underneath them — what "active customer" or "churned" means has to be defined once, centrally, not reinvented per tool.

Next: Organizing Marketing Information for Self-Service →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →