# Martech stack by industry: how SaaS, ecommerce, apps, marketplaces and regulated sectors differ

Canonical URL: https://www.martechdevs.com/blog/martech-stack-by-industry

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder at [Martechdevs](https://www.martechdevs.com) and [Growth and Analytics Partners](https://www.growthandanalytics.com)

[LinkedIn](https://linkedin.com/in/jafrinalo)

Published: 2026-10-17

Last updated: 2026-10-17

A martech stack changes by industry because the customer, valuable action, revenue record and permitted data flows change. The same CRM, analytics or messaging product can serve very different jobs. Start with the business model and the evidence each decision needs, then select tools that can preserve those definitions and restrictions. Copying another company's subscriptions skips the decisions that make its stack work.

## What actually changes from one industry to the next?

Five variables change the design: identity, the event that proves value, revenue ownership, permitted data flows and attribution visibility. The [layers every martech stack shares](https://www.martechdevs.com/blog/what-is-a-martech-stack) remain useful, but their connections must reflect your business.

Use this starting map to identify the records that must agree. The examples are design recommendations, not universal definitions for every company in a sector.

| Business model | Identity to preserve | Example value event | Revenue authority to reconcile |
| --- | --- | --- | --- |
| B2B SaaS | Person, workspace and customer account | First usable result for an eligible account | Billing/subscription ledger, with CRM commitments separate |
| Ecommerce | Customer and order | Confirmed purchase retained after refunds | Store and payment/refund records |
| Subscription app | App user, store purchase and entitlement | Paid entitlement or meaningful repeat use | Verified store transactions and backend entitlement state |
| Marketplace | Person with buyer/seller roles; transaction | A successfully fulfilled match | Transaction, fees, refunds and payout ledgers |
| Fintech | Applicant, verified customer and financial account | Approved operational milestone | Financial/accounting system and transaction records |
| Healthcare | Patient or consumer, care journey and permitted identity | Confirmed booking or completed service | Scheduling, care and billing systems for their respective facts |
| Edtech | Learner, guardian, teacher and purchasing organisation | A defined learning or adoption outcome | School contract or parent subscription, depending on the motion |

### How does the identity unit affect the stack?

A person can belong to two SaaS workspaces, buy and sell in a marketplace, or pay for a child's education. Those relationships should not collapse into one mutable `customer_type` field.

Segment's Group specification illustrates the B2B distinction by associating a user with a company, organisation or account through a separate group ID. It also cautions that destinations differ in their support for multiple groups. [Segment Group specification](https://www.twilio.com/docs/segment/connections/spec/group).

Write [identity rules across web, app, CRM and billing](https://www.martechdevs.com/blog/identity-resolution-startups) before choosing audience-sync software. Preserve the relationship at the time of the event when later membership changes would alter the interpretation.

### Which event proves value?

Select an observable result that the product can confirm. A marketplace signup does not prove a successful match; an intake submission does not prove an appointment exists. Keep attempted, accepted and completed states separate where the business distinguishes them.

Name the counting unit and eligibility rule. Five employees using one SaaS account are not five customers. Two retries of one store order are not two purchases. A trial's first result may matter more than the number of screens viewed.

### Which system owns revenue?

Identify the record that establishes each financial fact. A CRM opportunity records a commercial expectation; billing records a subscription or invoice; a payment system records money movement. Their values can legitimately differ.

For a marketplace, distinguish transaction volume, platform fees and seller payouts. For a subscription app, distinguish purchase state from current access. Reconcile these facts before asking an attribution model to explain them.

### Which data may reach each destination?

Specify the purpose and recipient for each field, including information carried indirectly by URLs, event names and audience membership. A destination's technical API acceptance is not approval to send the data.

Regulated data can require contracts and safeguards, while platform terms may independently prohibit its use. The legal examples below are a starting point for qualified review, not a determination of every company's obligations.

### How much attribution can you observe?

Record which parts of the journey are visible, which are inferred and which cannot be joined. Browser restrictions, consent choices, mobile platform rules and offline sales activity create different evidence boundaries.

Do not force every industry into a single last-click report. Compare attributed results with first-party outcomes and preserve an unattributed category. Missing attribution is a measurement limitation to explain, not a reason to manufacture an identifier.

## How do B2B and B2C patterns change the buying decision?

Choose account and opportunity workflows when buying decisions happen across a business relationship; choose customer, order and lifecycle workflows when individual transactions or subscriptions drive the job. Many companies need both patterns.

| Situation | Start with | Add only when the need is demonstrated |
| --- | --- | --- |
| Sales-led B2B with a manageable pipeline | CRM ownership, opportunity stages and billing reconciliation | Product signals that improve a named sales or retention decision |
| Self-serve consumer product | Confirmed outcome events, customer state and permitted messaging | A warehouse or CDP for recurring joins and audience requirements |
| Product-led SaaS with sales assistance | Workspace identity plus explicit sales handoff | Account summaries that explain product use without duplicating contacts |
| School contracts plus parent subscriptions | Separate purchasing and learner relationships | Shared reporting only after permissions and purpose are defined |

For eligible B2B acquisition work, [offline conversion import](https://www.martechdevs.com/blog/offline-conversion-import) can connect qualified outcomes to advertising. It is still subject to the destination's data and policy requirements. A lead becoming qualified internally does not automatically make every associated field eligible for upload.

Budget each product's actual meter. Sales seats, analytics events, stored profiles and message volume can all appear in one stack. The [Klaviyo active-profile guide](https://www.martechdevs.com/blog/klaviyo-active-profiles) shows why a stored customer record and a sent email are different units.

A [martech integration service](https://www.martechdevs.com/martech-integration) should define these ownership and field mappings before connecting the tools. An integration that moves records quickly can still move the wrong meaning.

## What changes for B2B SaaS?

The central relationship is usually the product account or workspace, connected to people, billing customers and CRM companies. The sales motion decides which workflow coordinates the next action.

For a sales-led company, start with opportunity ownership, stage definitions and the handoff into a paid account. For a product-led company, start with account creation, activation and billing state, then define when sales involvement becomes useful. A hybrid needs an explicit rule for when self-serve usage becomes a sales-owned opportunity.

Keep `account_id`, `workspace_id` and the billing customer identifier mapped deliberately. One billing customer can pay for several workspaces; one person can use several accounts. Test that case before scoring “engagement” or triggering a renewal message.

Postpone a broad CDP purchase until a recurring collection, identity or activation job requires it. A small reviewed account model can be enough to explain which customers activated, which paid and who needs a follow-up.

## What changes when Shopify owns the checkout?

Use the order as the unit for purchase reconciliation and let the supported checkout integration determine where tracking can run. Keep refunds, payment state and margin separate from an ad platform's attributed value.

Shopify's non-Plus upgrade deadline for the new Thank you and Order status pages was 26 August 2026. Its current guide directs stores to replace incompatible customisations with supported blocks and pixels. An old Additional scripts tutorial is therefore not a reliable implementation plan for a current checkout. [Shopify's upgrade guide](https://help.shopify.com/en/manual/checkout-settings/customize-checkout-configurations/upgrade-thank-you-order-status/upgrade-guide).

Shopify's Customer Privacy API applies consent decisions to Shopify-managed surfaces such as pixels, audiences and checkout. Verify your implementation and merchant settings rather than assuming a banner controls every custom script. [Customer Privacy API](https://shopify.dev/docs/api/customer-privacy).

Test one paid order, a failed payment, a repeated confirmation view and a refund. Use the order ID to investigate [GA4 purchases that differ from Shopify](https://www.martechdevs.com/blog/ga4-shopify-purchase-mismatch). Only after the revenue records reconcile should a channel comparison influence spending.

## What changes for a mobile subscription app?

Verified purchase and entitlement state must anchor revenue and access, while platform permissions constrain cross-company attribution. An install is not a paid subscriber, and a renewal notification is not a new acquisition.

Apple documents App Store server notifications for subscription-state changes. Google Play's real-time developer notifications tell the backend that a purchase state changed and require a Developer API lookup for complete status. Build the entitlement update around verified state, retries and cancellation timing. [Apple subscriptions](https://developer.apple.com/app-store/subscriptions/), [Google Play notifications](https://developer.android.com/google/play/billing/rtdn-reference).

Apple's App Tracking Transparency (ATT) guidance requires permission for its defined cross-company tracking; without permission, the IDFA is all zeros. Its documentation describes an alternative EU prompt beginning with iOS and iPadOS 27.2 while retaining the permission requirement. Do not assume a changed prompt permits a different tracking purpose. [Apple privacy rules](https://developer.apple.com/app-store/user-privacy-and-data-use/).

Keep permitted lifecycle reach separate from analytics identity. A useful internal user record does not prove push, email or advertising permission. The [mobile attribution guide](https://www.martechdevs.com/blog/mobile-app-attribution) explains the differing evidence available from attribution systems; evaluate a mobile measurement partner (MMP) against the networks and questions you actually need.

## What changes for a two-sided marketplace?

Model the person, role and transaction separately. A buyer can later become a seller, and a seller payout is not platform revenue.

Stripe Connect is designed for platforms and marketplaces moving money between multiple parties. Its connected-account and payment flows are implementation choices; your ledger still needs to explain transaction value, platform fees, refunds and payouts. [Stripe Connect](https://docs.stripe.com/connect).

For a hypothetical USD 100 completed transaction with a USD 12 platform fee, the platform's gross transaction volume is USD 100 and the fee is USD 12 before other costs. Reporting both as revenue would mix different measures. A later refund or fee adjustment needs its own recorded effect.

Track whether suitable supply meets demand: search-to-match, fulfilled transactions and repeat participation by role. A large user count can coexist with poor liquidity. Buy tooling that can preserve the role and transaction relationships; do not merge them just because a messaging platform expects one flat profile.

## What changes for fintech?

Keep verified identity, application decisions and funding milestones in the controlled backend, then approve any external measurement flow separately. A neutral event name does not remove the financial information implied by the action.

Google's personalised-advertising policy restricts advertiser-curated audiences in sensitive categories, including negative financial status. Its US/Canada consumer-finance rules also restrict specified demographic and ZIP-code targeting. [Google targeting policy](https://support.google.com/adspolicy/answer/143465).

Regulation P's general third-party disclosure rule requires the applicable initial and opt-out notices, a reasonable opportunity to opt out and no opt-out, subject to its stated exceptions. Do not erase those exceptions or assume they authorise every marketing integration. [CFPB Regulation P](https://www.consumerfinance.gov/rules-policy/regulations/1016/10/).

Meta also documents restrictions on custom conversions that imply health conditions or financial status, rolling out from 2 September 2025. A changed name is not a substitute for an allowed data use. [Meta conversion restrictions](https://developers.facebook.com/docs/meta-pixel/implementation/conversion-tracking/).

Use the internal milestone to operate the application process. Have legal and platform-policy review determine which, if any, external conversion or audience flow is appropriate. Never place credit scores, account details or sensitive eligibility outcomes in general analytics parameters to make a funnel more detailed.

## What changes for healthcare and health technology?

Classify the actual care and consumer-health flows before deciding where analytics or messaging can run. The contract and permitted purpose matter alongside the event schema.

Where an analytics vendor acts as a business associate handling protected health information (PHI), a suitable business associate agreement (BAA) and approved processing arrangement are required. Google does not offer a BAA for Analytics. [HHS business-associate guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html), [Google Analytics policy](https://support.google.com/analytics/answer/13297105). Follow the [HIPAA-compliant analytics setup guide](https://www.martechdevs.com/blog/hipaa-compliant-analytics) and the specific review of [Google Analytics on healthcare pages](https://www.martechdevs.com/blog/google-analytics-hipaa), rather than treating a healthcare landing page like an ordinary store page.

The 2024 partial vacatur of HHS tracking guidance is not a blanket approval of all health-data tracking. Consumer-health services outside HIPAA can face FTC and state rules too. The FTC's July 2026 Hims & Hers complaint, for example, alleges privacy violations involving customer lists and website events; allegations are not findings. [FTC complaint announcement](https://www.ftc.gov/news-events/news/press-releases/2026/07/ftc-states-act-against-hims-hers-deceptive-unlawful-privacy-practices).

Keep care-related email, CRM records and advertising destinations in the same recipient review. A BAA for one analytics product does not approve a separate email service, ad platform or AI feature.

## What changes for edtech and children's products?

Separate the learner, guardian, teacher and purchaser, then tie collection to the authorised purpose. A district purchasing a product does not turn children's activity into an ordinary business-contact dataset.

The amended rule under the Children's Online Privacy Protection Act (COPPA) had a general compliance deadline of 22 April 2026, with specified exceptions. It requires separate verifiable parental consent for certain non-integral third-party disclosures, including targeted-advertising uses, and strengthens retention requirements. Schools' authorisation for educational collection cannot be repurposed into other commercial uses such as marketing. [Final COPPA rule](https://www.govinfo.gov/content/pkg/FR-2025-04-22/html/2025-05904.htm), [FTC edtech policy](https://www.ftc.gov/news-events/news/press-releases/2022/05/ftc-crack-down-companies-illegally-surveil-children-learning-online).

Google says users under eighteen are not eligible for personalised advertising and restricts uploading information from viewers of child-directed content. These platform rules do not disappear because a parent accepted a product's terms. [Google targeting policy](https://support.google.com/adspolicy/answer/143465).

Check each destination's own child-data terms before enabling its SDK.

Design an adult purchasing journey separately from the learner experience. Use approved internal adoption and learning measures for the latter. Review SDKs, replay, error reporting and exports before launch; an age label in a database does not automatically control those paths.

## How do you adapt a reference stack to your own business?

Write the identity, outcome, revenue and routing decisions before mapping them to products. Use a concrete journey that the team already needs to improve.

1. **Name the unit.** Identify the person, account, role and business object, including legitimate one-to-many relationships.
2. **Name the outcome.** State its confirmed success condition and what must not count.
3. **Name the source record.** Identify who owns the outcome, amount, currency and later adjustments.
4. **Classify the data flow.** Include paths, titles, identifiers, forms, SDK context, logs and derived audiences.
5. **Approve destinations and channels.** Record purpose, applicable contracts, user permissions and platform restrictions.
6. **Run boundary tests.** Check retries, role changes, consent changes and movement between differently classified journeys.
7. **Buy only the missing capability.** Define the evidence that would justify adding a CDP, MMP, warehouse or new messaging channel.

The [reference stack examples](https://www.martechdevs.com/blog/martech-stack-examples) provide budget assumptions, but apply this model before copying their tools. The [startup stage guide](https://www.martechdevs.com/blog/martech-stack-for-startups) helps size the operating capacity the team can support; industry rules determine which flows are acceptable at any stage.

![Business model leads to identity and authoritative outcomes, then a destination approval decision; rejected flows are redesigned before synthetic testing and operating ownership.](https://www.martechdevs.com/assets/blog/martech-stack-by-industry.svg)

### What happens when a store adds a telehealth product?

Consider a hypothetical skincare store that adds a prescription service with a separate intake and care workflow. The new flow changes the data boundary even if the brand, domain and checkout software remain familiar.

| Flow | Proposed starting rule | Release test |
| --- | --- | --- |
| General store content and ordinary products | Retain only the reviewed commerce measurement | Confirm payload and product context remain within approved use |
| Prescription information, intake and booking | Block general ad and analytics destinations pending review | Synthetic health details do not reach those recipients |
| Care workflow | Use the separately approved contracted environment | Outcome reconciles with the care/scheduling system |
| Shared navigation and customer record | Apply the restrictive routing decision to the shared flow | Moving between areas cannot reactivate prohibited collection |

The technical implementation needs more than a page-name filter. A global tag can remain loaded when a single-page application enters intake. A product feed can reveal a prescription product even if the purchase event is called `order_created`. A customer-list export can disclose care participation without including a diagnosis field.

Keep consumer marketing and patient communications separated by approved purpose and eligibility. Only send an external commerce outcome after reviewing whether the order and its context are appropriate for that recipient. Hashing the email or replacing the product name with a code does not settle the question.

A compact routing decision record helps the next developer preserve the boundary:

```yaml
journey: prescription intake
identity_unit: protected care record
outcome_owner: scheduling system
approved_measurement_purpose: pending privacy review
allowed_destinations: []
public_ad_destinations: blocked
raw_urls_and_form_values: excluded from general telemetry
new_routes_default: blocked pending review
release_test: synthetic intake marker absent from general analytics
change_owner: named engineering and privacy owners
```

This is an illustrative operating record, not a vendor configuration or a compliance certificate. The empty destination list is intentional until the relevant processing is approved.

## What should you avoid copying from another company's stack?

Avoid copying a tool list without the identity model, data boundaries and operating work behind it. The [decisions that become expensive to change](https://www.martechdevs.com/blog/scalable-martech-stack) often sit between products rather than inside their feature lists.

Do not assume a store's pixel setup fits a health intake, a consumer profile fits a buying committee, or an app's attributed install equals a paid subscription. Do not treat a vendor's broad compliance statement as coverage for every feature or export.

Also avoid buying infrastructure before a recurring job justifies it. A warehouse is useful when the team needs governed joins and a maintained model; it still requires ownership. A CDP can help operate collection and activation; it still needs rules about which data may go where. Use the [CDP versus warehouse guide](https://www.martechdevs.com/blog/cdp-vs-data-warehouse) to separate those jobs.

## What should pass in an industry-specific stack review?

Approve the stack when its identity, outcome and data-flow decisions can be demonstrated through a controlled journey:

## Checklist

- [ ] People, accounts, roles and transactions have distinct identifiers where needed.
- [ ] The value event has a confirmed success condition and counting unit.
- [ ] Revenue, refunds, entitlements and payouts have authoritative records.
- [ ] Each page and screen is classified by the data it can expose.
- [ ] Every destination has an approved purpose and relevant contractual scope.
- [ ] Platform restrictions are checked before defining events or audiences.
- [ ] Channels respect their own consent and permission requirements.
- [ ] Attribution limits and unattributed outcomes remain visible.
- [ ] Shared scripts and cross-journey navigation pass boundary tests.
- [ ] Each new tool has a concrete job, owner and acceptance test.

At Martechdevs, we work with your developers to connect those definitions to the actual tools and tests. Start with a [free stack audit](https://www.martechdevs.com/martech-ai-audit), or [request an integration quote](https://www.martechdevs.com/martech-integration#get-quote) scoped to the flows and decisions your business needs.

## Frequently asked questions

### When should a startup choose a tool built for its specific industry?

Choose it when a required data model, workflow or contractual arrangement is materially easier to operate and verify there. Compare that advantage with migration, integration and ownership costs. A healthcare agreement or marketplace payout model can justify a specialist; a matching industry label alone does not prove the product will answer your first business question.

### Is a CDP automatically more valuable for B2C than B2B?

No. Value comes from recurring collection, identity and activation work that the team cannot reliably handle otherwise. Consumer scale can increase that need, while a B2B company may have equally difficult account relationships or routing requirements. Define the job, volume and failure cost before deciding whether the CRM, warehouse or a CDP should perform it.

### How should we review a tool that will serve both adults and children?

Map the adult purchasing and learner journeys separately, including SDKs, identifiers, messages and exports. Identify which purposes and permissions apply to each, then test that shared code cannot send learner activity through the adult marketing path. Keep the relevant privacy owner involved; a single account-level age flag is not evidence that every destination follows it.

### What should we do when two business lines share one analytics property?

Review whether their data classes, authorised purposes and operating owners actually fit that shared setup. Separate properties or domains can make controls clearer, but do not isolate data by themselves. Test shared tags, user identifiers, exports and navigation. Use the stricter approved route where a shared component cannot reliably distinguish the flows.

### How do we know an industry difference justifies more infrastructure?

Name the recurring decision or control that the current setup cannot support, then estimate the effort and consequence of that gap. Run a small pilot with explicit acceptance criteria. Add infrastructure when it improves that job enough to cover its ongoing ownership cost, rather than because another company in the industry already bought it.

## Sources

1. [Meta: Custom-conversion restrictions](https://developers.facebook.com/docs/meta-pixel/implementation/conversion-tracking/)

2. [HHS: Business associates](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html)


3. [Twilio Segment: Group specification](https://www.twilio.com/docs/segment/connections/spec/group)

4. [Shopify: Non-Plus Thank you and Order status upgrade](https://help.shopify.com/en/manual/checkout-settings/customize-checkout-configurations/upgrade-thank-you-order-status/upgrade-guide)

5. [Shopify: Customer Privacy API](https://shopify.dev/docs/api/customer-privacy)

6. [Apple: Auto-renewable subscriptions](https://developer.apple.com/app-store/subscriptions/)

7. [Apple: User privacy and data use](https://developer.apple.com/app-store/user-privacy-and-data-use/)

8. [Google Play: Real-time developer notifications](https://developer.android.com/google/play/billing/rtdn-reference)

9. [Stripe: Connect](https://docs.stripe.com/connect)

10. [Google: Personalised-advertising targeting restrictions](https://support.google.com/adspolicy/answer/143465)

11. [CFPB: Regulation P section 1016.10](https://www.consumerfinance.gov/rules-policy/regulations/1016/10/)

12. [FTC: Final COPPA amendments](https://www.govinfo.gov/content/pkg/FR-2025-04-22/html/2025-05904.htm)

13. [FTC: Edtech privacy policy statement](https://www.ftc.gov/news-events/news/press-releases/2022/05/ftc-crack-down-companies-illegally-surveil-children-learning-online)

14. [FTC: Hims & Hers complaint announcement](https://www.ftc.gov/news-events/news/press-releases/2026/07/ftc-states-act-against-hims-hers-deceptive-unlawful-privacy-practices)

15. [Google: HIPAA and Google Analytics](https://support.google.com/analytics/answer/13297105)

16. [HHS: Online tracking technologies and court notice](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html)