EdgeAngel is a data marketing and AI agency, and an independent consultancy. We have worked on marketing and analytics data since 2018, on scoped engagements or embedded alongside your teams.
Data platform, collection and pipelines: what we take on
Some clients call us to build from scratch, others have a warehouse that runs and figures they no longer trust, others want to activate what they already have. We come in at the link that is missing.
01
Data platform: selection, migration and setup
The platform choice commits you for several years. It is decided on your use cases, your teams and your cloud, and everything is built inside your own project.
Audit of what exists: sources, real uses, costs, what has to migrate
Selection: BigQuery, Snowflake, Databricks or Microsoft Fabric, depending on your cloud and your teams
Setup inside your cloud project: environments, IAM and access governance, infrastructure as code
Migration from an on-premise warehouse or another cloud, data and models, uses kept running during the switch
FinOps: storage and query costs scoped from the design stage, then tracked
GDPR compliance and hosting in Europe, a data lakehouse when your volumes call for it
02
Tracking and compliance
The chain starts on your site and your app. We design the collection, verify it and align it with consent, and it lands in the warehouse with its documentation.
Tagging plan: every event, its parameters, its expected value, web and app
GTM web and server-side (sGTM): tags, triggers, enriched hits
CMP and Consent Mode v2: collection aligned with consent, and the proof
Raw export to the warehouse: Google Analytics, Piano, Segment, back office
QA and monitoring: every event verified, alerts on volumes
GDPR and ePrivacy compliance: vendor register, hosting in Europe
Synchronise your sources, prepare your data and send it back to your tools, with solid, versioned and monitored flows.
We operate an ingestion platform for our clients, API-driven and scripted: a new scope is deployed and documented in a few days. We are an Airbyte Partner, and we also work on the ETL tools already in place at your end.
ETL and ELT: Airbyte, Fivetran, native connectors, or a connector written for your source
Validated synchronisations: schedule, retries on failure, history, one single place to know whether a flow ran
dbt or Dataform models: raw, prepared and business layers, tests, data lineage, version history
Semantic layer and catalogue: every definition written once, readable by a human and by an agent
Reverse ETL: audiences, conversions and scores sent back to your ad platforms, your CRM and your business tools
Checks on freshness, completeness and accuracy, with alerts
The transformation code lives in a versioned repository, with its history. You can read it, take it over, or hand it to someone else.
Our consultants work on your stack, whatever it is. The tools that come up most often in our projects:
BigQuery Google Cloud data warehouse: datasets, partitioning, query costs, native exports from Google Analytics and Google Ads.
Snowflake and Databricks Warehouse and lakehouse on AWS or Azure: modelling, access governance, compute cost control.
Airbyte Open-source ELT ingestion: connectors, scheduled syncs, API-driven platform. We are an Airbyte Partner.
dbt Versioned SQL transformation: models, tests, documentation and data lineage, on any warehouse.
Dataform BigQuery-native transformation: SQLX, releases and scheduled workflows, inside your Google Cloud project.
Knowledge Catalog The Google Cloud catalogue (Dataplex Universal Catalog): business definitions, glossary, aspects and lineage, readable by your teams and your agents.
Our data engineering support, from the business need to the run
Each block is replaceable on its own. The choice depends on your cloud, your teams and your use cases, and it gets revisited.
01
Express the business need and map the data
We start from your business questions and the decisions they serve: which indicators, at which grain, how often, for whom. We then map the data needed, its sources, its owners and its rules, and we write the definitions with the teams that own them. That document frames the architecture, the flows and the order of the work.
A business question, an indicator, a definition, a source. This table decides what gets connected, and in which order.
02
Centralise in a data warehouse
Your sources land in a warehouse that lives inside your cloud project: ad platforms, analytics, CRM, back office, product. We choose the method source by source, off-the-shelf connector, native export or a connector written for you, and we validate every synchronisation: schedule, retries on failure, history, freshness and completeness checks. One single place says whether a flow ran.
Sources arrive exactly as they are. Normalisation happens in the warehouse, where it can be read.
03
Model the data
Raw data becomes a figure someone can quote in a meeting. We write your business rules in SQL, with dbt or Dataform: a raw layer, a prepared layer, business tables per use, consistency tests, data lineage and version history. The code lives in a versioned repository your teams can read, take over or hand to someone else.
The join that connects money collected to the click paid for, and the calculation rule exactly as it is written.
04
Document: semantic layer and catalogue
Every table and every field carries its definition, written once: what counts as a conversion, how a ratio is computed, where a dimension comes from. Those definitions live in a catalogue or a semantic layer, Knowledge Catalog on Google Cloud, dbt Semantic Layer or the equivalent in your stack, and never in the tables. Your analysts, your dashboards and your AI agents read the same definition, and a rule that changes is fixed in one place.
The definition is written once, in the catalogue. Tables carry no business rule, so a single truth circulates.
05
Activate the use cases
Modelled, documented data goes back to what produces a result. BI and reporting: steering dashboards on a single source. AI and agents: agents that query documented tables and trace every answer back to its definition. Data activation: reverse ETL to your ad platforms, your CRM and your business tools, with first-party audiences and enriched conversions. The same figure serves human decisions and automated bidding.
The same figure serves human decisions and automated bidding. That is what keeps the two consistent.
06
Keeping the chain alive: run, support and training
A data chain keeps moving with your business. After go-live, a consultant stays at your side on a monthly run: they monitor the flows and the costs, evolve the models and the catalogue when your sources and schemas change, answer your teams and train them on the warehouse, the catalogue and the tools. Topics are decided together, and the skills move into your team whenever you want to take over.
The run keeps the chain reliable and evolves it: a monthly rhythm, topics decided together, and skills that move into your teams.
We work autonomously on the scope you entrust to us, or alongside your IT department, your data teams and your integrators. How the work is split is decided at kick-off, and adjusted as the project runs.
Our lead profiles on data engineering and modern data stack services
Mathieu Lima
Data Foundations Director and CTO
Co-founder
Télécom SudParis engineer
Institut Mines-Télécom
Olivier Chubilleau
CEO, co-lead Data Engineering
Co-founder
Institut Mines-Télécom Business School
Our engagement formats
Embedded consultant
A consultant embedded in your team and your rituals, for a defined period.
Data engineer, analytics engineer or data architect, depending on the need
Per day or fixed price, at the pace of your sprints
The skills transfer to your team
Project
A project with a scope, a schedule and named deliverables.
Framing, ingestion, modelling, catalogue and activation
First data in production within weeks, then extension
The code, the models and the documentation are yours
Our expert profiles
Data EngineerBuilds and operates the ingestion pipelines and the warehouse.
Analytics EngineerModels and documents the data your tools and your agents read.
Data ArchitectDesigns the target architecture and arbitrates technical choices.
DataOps EngineerIndustrialises deployment, orchestration and monitoring.
Data AnalystBuilds the dashboards and the analysis on the delivered model.
Data marketing consultantConnects the business need with the data that is available.
The agency
An independent firm of senior consultants, founded in 2018.
Hubs in Paris, Bordeaux and Barcelona. You know who works on your account, and you talk directly to the consultants who run it.
An acquisition strategy that perfectly secured our high season. Thanks to fine-tuned management of the Google / Meta complementarity, we were able to scale our volumes with controlled profitability.
Lydie Castagnet Marketing & Communication Director Forge Adour
EdgeAngel is not limited to media buying, they give meaning to numbers. They were able to detect weak signals in our data to transform our acquisition and unlock new performance levers.
Valentine Soulès E-commerce Manager Golf One 64
Since the deployment of Capture by EdgeAngel, our SEO team has significantly improved reporting quality and opportunity analysis: the reports are highly performant, with very advanced granularity (+30 million rows in the dataset) and complete team adoption.
Karim Elmlih Head of Organic Acquisition – Growth Qonto
Partners since 2018 on our tracking and privacy challenges (Piano, sGTM, GDPR), EdgeAngel combines sharp technical expertise with rigor. An essential extension of our team to secure and accelerate our complex data projects.
Cédric Tamboise Group Digital & e-Commerce Director Kiloutou
Since 2021, EdgeAngel has been securing our Web & App tracking. Their advanced technical expertise has enabled us to regain full control of our data to effectively drive the evolution of our digital ecosystems.
François Charlet Communication and Digital Marketing Citeo
With the Capture solution for our reporting and the quality of consultants, our performance reviews have become ultra-clear and relevant. This allows us to manage daily activities and gives us the means to achieve our goals.
Mathias Pestre-Mazieres CEO Blue Horse Group
Solution
Capture: the modular Data Platform to activate your Marketing & AI data.
Connect your tools to each other and feed your AI and agentic workflows with your data and your business context. Capture augments your existing infrastructure and makes it more efficient: you remain the owner of the tools and the data.
Frequently asked questions about the Modern Data Stack
What is a Modern Data Stack?
A Modern Data Stack is a set of specialised building blocks that collect, centralise, transform and activate a company data, connected by automated pipelines. Each block is replaceable independently of the others.
In practice: ingestion brings the data in, the warehouse stores it, transformation shapes it according to your business rules, activation sends it back to your tools. Governance and documentation run across all four.
Which tools make up a Modern Data Stack?
A Modern Data Stack is organised in six categories:
Ingestion and synchronisation: Airbyte, Fivetran, Stitch
Storage and warehouse: Google BigQuery, Snowflake, Databricks
Transformation: dbt, Dataform
Activation and reverse ETL: Hightouch, Census, Segment
Visualisation and BI: Data Studio, Power BI, Metabase
Governance and semantics: data catalogue, semantic layer, data lineage, access control, GDPR compliance
The choice depends on your maturity, your teams, your cloud and the use cases you target.
On sovereignty, a European foundation is a real decision criterion: OVHcloud and Scaleway on the cloud side, Didomi on consent management. It is addressed at the framing stage, with your regulatory constraints.
What is the difference between a Modern Data Stack and a data platform?
The Modern Data Stack refers to the modular blocks that collect, transform and activate data. The data platform refers to the technical foundation they sit on: cloud infrastructure, storage, orchestration, security, access management.
The two are designed together. A stack built on a poorly scoped foundation is expensive to operate and hard to evolve, and a foundation with no uses is just a cloud bill.
BigQuery, Snowflake or Databricks: how do you choose?
The choice is made on your cloud, your internal skills and your cost profile. If you are already on Google Cloud, BigQuery is the short path: per-query billing, no cluster to size, native integration with the advertising and analytics ecosystem. On AWS or Azure, or with teams already trained, Snowflake and Databricks have their arguments, particularly on heavy compute workloads and machine learning.
Our deepest expertise is on BigQuery, and we say so. If your foundation is elsewhere, we work on it: designing the model weighs more than the engine that runs it.
dbt or Dataform for transformation?
Both do the same job: writing SQL transformations that are versioned, tested and documented. dbt is the market standard, with the largest ecosystem and community, often the right choice if your teams already know it or if your warehouse is outside Google Cloud. Dataform is native to BigQuery, with no extra licence and no separate orchestrator, and it lives inside your Google Cloud project.
We work with either. What matters more: that models are versioned, that business rules are written down and that tests exist.
What is a semantic layer or a data catalogue for?
For writing every business definition once, outside the tables, and making it readable by everything that consumes the data. A semantic layer carries the metrics and the dimensions: the formula of a cost per lead, what counts as a conversion, how a channel is derived from a source. A data catalogue carries the documentation of tables and fields, the business glossary and the data lineage.
In practice, for our clients on Google Cloud, the definitions live in Knowledge Catalog (Dataplex Universal Catalog) and are applied as code, versioned in a repository. Your dashboards, your analysts and your AI agents read the same definition, and a rule that changes is fixed in one place. On another stack, dbt Semantic Layer or the catalogue of your warehouse plays the same role.
Does a CDP replace a Modern Data Stack?
No, they answer two different needs. A CDP unifies customer profiles and activates them towards marketing tools, with an interface built for business teams. A warehouse stores all of your data, including what has nothing to do with the customer, and serves analysis as much as activation.
Three situations come up in practice. You have a CDP: we integrate it into the chain and feed it from the warehouse, which stops it becoming a second source of truth. You are evaluating one: we scope what it adds against a warehouse plus reverse ETL. You would rather do without: the function is covered by the warehouse, the modelling and the activation.
How do you know the figures coming out of the stack are accurate?
Through a written control. We publish a reconciliation between the table exposed to the tools and the production view that serves as reference: the same aggregates, over the same period, row by row, with the gap shown. The control is replayed on every change to the model.
Alongside that, consistency tests run on the models, freshness and completeness checks run on ingestion, and data lineage says where each field comes from. Missing data stays empty and gets flagged.
Who owns the code and the data in the stack?
You do. And it is a question worth asking any provider, because the answer varies.
With us: the warehouse and the modelled tables live in your own cloud project, the transformation code is versioned in a repository with its history, and the model documentation is delivered. If you take over or change partner, you leave with all of it.
One honest nuance: depending on the architecture chosen, part of the ingestion flow may transit through a platform we operate. That is a choice discussed at the framing stage, and it is documented.
How long does a first chain in production take?
A few weeks for a first scope delivered and documented: two or three sources, a warehouse, a model and one use served. A few months for a complete chain across all sources.
The factor that weighs most is access. Getting the rights on an ad platform, a CRM or a back office often takes longer than connecting the flow, and it is prepared from the framing stage.
Can you take over an existing stack?
Yes, and it is the starting point of many of our projects. A stack taken over comes with its reasons: a provider gone, a team that changed, a project stopped halfway.
We start with a review: what runs, what stopped running without anyone noticing, what is documented, what it costs. Then we decide with you what is kept, what is rebuilt and what is switched off. We also know how to hand a stack we built over to your teams or to another partner.