Portfolio and repository baseline
Public surfaces, evidence boundaries and release controls were reconciled before measurement was added.
CASE STUDY · PERSONAL MARTECH LAB
Personal MarTech Ecosystem: Architecture, Implementation and Evidence
A governed, configuration-aware digital ecosystem built to connect marketing technology, analytics, data engineering and research evidence without treating any single platform as the system of record.
Primary artefactConfigured MarTech ecosystem
Evaluation approachLongitudinal Design Science
Canonical data formatParquet
Analytical engineDuckDB
01 · PROBLEM
From a collection of tools to an observable system
Marketing platforms are easy to add independently. The harder problem is preserving coherent event semantics, consent rules, provenance, reproducibility and analytical portability as the stack evolves. This project treats the ecosystem configuration itself as the artefact under study rather than evaluating isolated tools.
Design objective: build the smallest viable MarTech ecosystem in which public touchpoints, governed events, provider telemetry, canonical analytical evidence and later evaluation can be traced across configuration changes.
02 · ARCHITECTURE
Separate source, canonical storage and analytical compute
The architecture deliberately separates provider-managed raw data from canonical analytical evidence and from the compute engine used to query it. This keeps the research evidence portable while allowing provider-specific adapters to change.
Public surfaceyobany.topcontent + interaction
Collection controlGTM + consentgoverned event dispatch
Provider telemetryGA4behavioural events
Managed raw sourceBigQueryraw GA4 event export
Canonical evidenceParquet on Backblaze B2remote durable analytical data
Analytical computeDuckDBSQL + reproducible analysis
Dashboards
Research
AI
Decisions
03 · IMPLEMENTATION
Incremental implementation with runtime verification
Performance, accessibility and security hardening
Repository-level quality controls were added while preserving runtime-only measurements as separate evidence.
Consent-aware GTM and GA4
Optional analytics loads only after explicit consent; denied-consent behaviour was tested as a separate path.
Governed event model
Five behavioural events were mapped and validated while provider-automatic events remained semantically separate.
Search and SEO observability
Search Console ownership and a governed technical/on-page SEO contract were established without claiming ranking effects.
Canonical remote analytics path
A real governed GA4 validation batch was conformed, materialised as versioned Parquet on Backblaze B2, remotely reconstructed with DuckDB and accepted after identity, temporal, semantic and SHA-256 integrity checks.
04 · CURRENT STATE
What is operational, validated or still pending
| Capability | State | Evidence boundary |
|---|---|---|
| Portfolio release and governance | Operational | Versioned repository and release-quality controls. |
| Google Tag Manager | Operational | Deployed and provider-detected under strict Basic Consent Mode. |
| GA4 collection | Operational | Consent-aware production telemetry verified. |
| Governed behavioural events | Operational | Five event mappings validated in positive and denied-consent paths. |
| Search Console | Operational | Domain ownership verified through DNS. |
| GA4 daily raw export | Operational | BigQuery daily export has supplied a real event-level validation batch; BigQuery remains a provider-managed non-canonical raw source. |
| Canonical GA4 Parquet evidence | Operational | Conformance-v2 materialised 13 accepted governed observations to versioned remote Parquet in B2 with 13 unique canonical IDs, zero null IDs and verified temporal/integrity evidence. |
| DuckDB ↔ B2 reconstruction | Operational | The accepted remote Parquet object was reconstructed and reconciled directly through DuckDB. |
| Minimum reproducible reporting surface | Operational | A controlled dashboard reports reconciliation, eligible validation metrics, regeneration SQL and explicit evidence boundaries. |
| Longitudinal P1 baseline | Not established | The accepted 13-observation object is pre-baseline validation evidence; a clean longitudinal outcome window has not been established. |
| Marketing outcome improvement | Not measured | No causal or longitudinal performance claim is made. |
05 · CAPABILITY EVOLUTION
Implementation maturity has advanced faster than outcome evidence
The project compares capability states qualitatively rather than collapsing them into one maturity score.
Operational3 → 6
Partially operational3 → 5
Designed6 → 4
Not established4 → 1
Measured0 → 0
The absence of any capability in the Measured state is intentional. Operationalisation is accepted only when the technical path is verified; measurement requires eligible observations over time.
06 · PRELIMINARY DESIGN LEARNING
Patterns emerging across implementation cycles
Runtime evidence is separate from source correctness
A merged configuration is not sufficient when caching, consent state, provider loading or deployment behaviour can change the effective system.
Consent is an architectural state
Consent determines whether collection infrastructure loads and therefore which evidence can legitimately exist.
Provider telemetry is not automatically canonical
Automatic events remain provider observations until explicit mapping and validation establish their analytical meaning.
Storage and compute can be decoupled
Canonical Parquet can remain remote while DuckDB provides lightweight local analytical compute.
Failures and recoveries are evidence
Documented corrections explain why architecture and governance rules changed rather than erasing the implementation path.
Unknown and pending states should remain explicit
The project records evidence gaps instead of replacing them with assumptions or synthetic performance claims.
These are preliminary cross-cycle insights, not final transferable design principles.
07 · NEXT ITERATION
The next evidence frontier is real longitudinal data
08 · PUBLIC EVIDENCE
Inspect the implementation surface
Private research-control documents, credentials and person-level data are not exposed. Public evidence is limited to artefacts that can be safely inspected without weakening the project’s governance boundary.