Most treatment center accounts I audit have conversion tracking that is either HIPAA-noncompliant, technically broken, or both.
The specific pattern is that a pixel got installed in Google Tag Manager three years ago, the person who installed it left the agency, the conversion events fire on the wrong pages, PHI leaks into query strings on the thank-you URL, and nobody has looked at it since.
The full stack for HIPAA-safe conversion tracking has four platforms and one connecting layer. Meta Conversions API on the Meta side. Google Enhanced Conversions on the Google Ads side. It is one of the load-bearing infrastructure investments inside the broader paid media stack our team runs.
Google Analytics 4 sits as the cross-channel measurement layer. GTM Server-Side as the connecting tissue that moves signal between the platforms without exposing PHI to client-side environments.
Getting any one of them right is a project. Getting all four working together is the difference between defensible conversion signal and the specific failure modes that break AI Max and Meta Advantage+ optimization.
This piece walks the full stack for the paid media programs we run at Webserv.
It covers the HIPAA constraint layer that shapes every configuration decision, the value-tier conversion event architecture that keeps AI-optimized campaigns from chasing the wrong outcome, and the specific setup steps for each of the four platforms.
It also covers the GTM Server-Side tissue that connects them and the monthly reconciliation cadence that catches signal drift before it produces the AI Max failure pattern documented separately.
It sits alongside our Meta Conversions API setup piece covering the Meta side in isolation and our Google Ads conversion tracking piece covering the Google side in isolation. The full-stack rollup is what ties the two into the measurement infrastructure that supports both paid attribution and organic attribution across the whole content SEO and paid book.
Key Takeaways
- The full HIPAA-safe conversion tracking stack has four platforms and one connecting layer. Meta Conversions API for Meta paid, Google Enhanced Conversions for Google Ads, Google Analytics 4 for cross-channel measurement, and GTM Server-Side as the connecting tissue. Configuring any single platform without the others produces measurement gaps that break AI-optimized campaigns.
- HIPAA is not the reason your conversion tracking is broken. Configuration is. But HIPAA is the constraint that makes correct configuration materially harder in behavioral health than in other verticals, because PHI cannot flow into client-side pixels, cannot appear in URLs or query strings, cannot appear in unhashed form on customer match uploads, and requires a BAA-covered server-side layer for transmission.
- The value-tier conversion event architecture is the single load-bearing configuration decision. Treatment center accounts that count form-fills, calls, and admits as one conversion event feed AI Max and Advantage+ a signal that optimizes toward whichever outcome is cheapest to produce, which is usually the lowest-value form-fill.
- Meta Conversions API is not optional in behavioral health. iOS ATT and browser privacy restrictions have degraded client-side pixel accuracy below the level where paid campaigns can optimize defensibly. Server-side transmission through Meta CAPI is the floor requirement for any treatment center running Meta paid at any scale.
- Google Enhanced Conversions is the Google-side equivalent to Meta CAPI. Enhanced Conversions transmits hashed customer identifier data server-side to Google Ads, which restores conversion accuracy in the environment where third-party cookies are dying. Not optional for Google Ads accounts serving BH.
- GA4 is the cross-channel measurement layer, not the source of truth. GA4 tells you which channels produced conversions; the CRM tells you which admits actually happened. The monthly reconciliation between GA4 reported conversions and CRM reported admits is the single audit that catches signal drift before it produces the AI Max failure pattern.
- The four-platform stack cannot compensate for a broken CRM or a broken CRM-to-attribution flow. If the CRM does not have clean lead source attribution and value-tier conversion event data, the stack has no defensible signal to transmit to Meta and Google. The admissions ops software stack map covers the CRM layer that has to be defensible first.
DEFINITION
HIPAA-safe conversion tracking stack. Four platforms and one connecting layer that transmit value-tier conversion signal from a treatment center’s CRM to Meta, Google Ads, and GA4 without exposing PHI to any client-side environment. Meta Conversions API (Meta paid), Google Enhanced Conversions (Google Ads), Google Analytics 4 (cross-channel measurement), and GTM Server-Side (connecting tissue that strips PHI, enforces consent, and deduplicates events).
Distinct from single-platform pixel tracking (which is broken by iOS ATT and third-party cookie deprecation) and distinct from the CRM itself (which is the source of truth, not the transmission layer). The stack is the precondition for AI-optimized paid campaigns (AI Max, Meta Advantage+) to work in behavioral health.
HIPAA CONSTRAINT LAYER
Meta, Google, and GA4 do not sign standard HIPAA BAAs for advertising products. This is the architectural reason the server-side layer matters: it strips PHI before the signal reaches the platform, so the platform never receives PHI, so the platform does not need a BAA. The container is the BAA-covered environment, not the ad platform.
Five constraints shape every configuration decision: no PHI in client-side pixels, no PHI in URLs or query strings or fragments, hashed identifiers only for customer match, server-side transmission for conversion signal, and BAAs with every platform that touches conversion signal (which in practice means only the server-side container). PHI in a thank-you page query string is a reportable HIPAA incident regardless of downstream sharing.
The HIPAA constraint layer
Every configuration decision in the stack lives inside the HIPAA constraint. Understanding the constraint before touching any platform is what separates a defensible setup from a compliance incident.
No PHI in client-side pixels. The client-side pixel is the JavaScript that fires in the user’s browser when a page loads or a conversion happens. Client-side environments are considered untrusted for PHI transmission under HIPAA. Names, dates of birth, medical record numbers, diagnoses, treatment types, and any combination of identifiers that could de-anonymize an individual patient cannot appear in a client-side pixel payload.
No PHI in URLs, query strings, or fragments. Thank-you pages, confirmation pages, and any URL that gets recorded in analytics platforms cannot carry patient identifiers. This includes the specific pattern where a form submission redirects to /thank-you?email=patient@example.com&condition=SUD. That URL logs the identifier into GA4, Meta pixel, and any other analytics platform on the page.
Hashed identifiers only for customer match and lookalike audiences. When you upload customer match lists to Meta and Google for lookalike targeting, email addresses and phone numbers must be transmitted hashed (SHA-256 typically). Uploading the raw email is a violation, and so is including any additional metadata alongside the hashed identifier (condition treated, LOC scheduled, admit date).
Server-side transmission for conversion signal. The server-side layer (GTM Server-Side, Meta CAPI, Google Enhanced Conversions server-side) is where PHI-adjacent conversion signal can be transmitted safely because the server environment is considered a controlled environment under HIPAA when configured with the appropriate BAA architecture.
BAAs with every platform that touches conversion signal. Meta, Google, and GA4 do not sign standard HIPAA BAAs for advertising products. This is the architectural reason the server-side layer matters: it strips PHI before the signal reaches the platform, so the platform never receives PHI, so the platform does not need a BAA. The container is the BAA-covered environment, not the ad platform.
Our HIPAA-compliant Facebook ads piece and our 42 CFR Part 2 marketing compliance piece walk the regulatory framework in depth. This piece is the configuration layer that keeps the platforms clean of PHI while still transmitting the conversion signal AI-optimized campaigns need to optimize defensibly.
The value-tier conversion event architecture
The single most consequential configuration decision in the stack is how conversion events get structured. Get this wrong and every downstream optimization runs against the wrong signal.
Four tiers, ranked by value to the treatment center.
Tier 1: Admit-day arrival
The patient physically arrives at the facility for admission. This is the highest-value conversion because it is the point at which reimbursement becomes possible. Value: the facility’s average revenue per admit (adjusted for payer mix). For a residential SUD operator with mixed payer mix, this is typically several thousand dollars per admit.
Tier 2: VOB-completed inquiry
The family has provided insurance information, VOB has run successfully, and the plan qualifies for admission. This is a leading indicator of Tier 1. Value: fractional to Tier 1, typically 15 to 25 percent of the admit value depending on the facility’s VOB-to-admit conversion rate.
Tier 3: Scheduled admission
The family has scheduled an admit day but has not yet arrived. Value: fractional to Tier 1, typically 40 to 60 percent depending on the facility’s no-show rate.
Tier 4: Qualified inquiry
The family has completed a form or a call that meets the qualification criteria (in-market, insurance profile viable, family decision-maker engaged) but has not yet completed VOB. Value: small, typically 5 to 10 percent of Tier 1.
Form-fills without qualification, brochure downloads, and general newsletter signups do not qualify as conversion events for AI-optimized campaign purposes. Feeding those into Meta CAPI or Google Enhanced Conversions as conversions produces the signal contamination that breaks AI Max and Advantage+.
The four tiers get transmitted with specific value fields set in the conversion event payload. AI Max and Advantage+ use those value fields to optimize toward the higher-value conversions.
When the value tiers are set correctly, the algorithms pursue Tier 1 and Tier 2 conversions preferentially. When they are missing or misconfigured, the algorithms chase Tier 4 form-fills at the expense of Tier 1 admits.
The conversion tracking stack at a glance
4 + 1
Meta CAPI + Google Enhanced Conv + GA4 + GTM Server-Side layer
4 tiers
Value-tier events: admit / VOB / scheduled / qualified inquiry
6-10 wk
Build timeline from decision to reconciliation-clean stack
$8-18K
One-time build + $200-500/mo container hosting
Meta Conversions API setup for behavioral health
Meta CAPI is the server-side transmission layer for Meta’s paid platforms (Facebook, Instagram, Audience Network). The setup has four load-bearing configuration steps.
Step 1: Deploy a server-side container
GTM Server-Side is the reference deployment. Some facilities run custom Node servers, but GTM Server-Side is the standard because Google supports it directly and the configuration is simpler. Deploy the container on a subdomain (sgtm.facilityname.com typically) with a BAA-covered hosting provider.
Step 2: Configure the CRM-to-server-side webhook
The CRM (Kipu CRM, Salesforce, HubSpot, whichever the facility runs) fires a webhook to the server-side container at the moment each conversion event happens. The webhook payload includes the value tier, the hashed customer identifier (email SHA-256), and the timestamp.
Step 3: Configure the server-side container to transmit to Meta CAPI
The container receives the webhook, formats the payload for Meta CAPI, and transmits via server-side call. Meta receives the conversion event with the hashed identifier and the value tier. No PHI touches the client-side pixel.
Step 4: Deduplicate against the client-side pixel
Meta CAPI events need to be deduplicated against any residual client-side pixel firing to prevent double-counting. The event_id field on both the CAPI event and the pixel event needs to match. Most facilities running the full server-side stack disable the client-side pixel entirely once CAPI is verified transmitting cleanly. Our Meta CAPI HIPAA setup piece walks the specific technical configuration in depth.
Google Enhanced Conversions setup for behavioral health
Google Enhanced Conversions is the Google-side equivalent to Meta CAPI. The setup has three load-bearing configuration steps.
Step 1: Enable Enhanced Conversions in Google Ads
In the Google Ads conversion settings, enable Enhanced Conversions for the specific conversion actions that will receive value-tier signal. The default is to enable Enhanced Conversions for leads only. For BH, enable for all four value tiers.
Step 2: Configure server-side transmission via the Google Ads Conversion API
GTM Server-Side supports the Google Ads Conversion API directly. The same server-side container that transmits to Meta CAPI transmits to Google Ads Conversion API in parallel. The payload includes the hashed customer identifier and the value tier per event. Our Google Ads conversion tracking piece walks the Google-specific implementation.
Step 3: Verify conversion events in Google Ads
Google’s Conversions view shows the count of Enhanced Conversion events received. Verify that the count matches the CRM’s count for the same period at a weekly cadence during the first 90 days after configuration. Drift between the two counts surfaces configuration errors early.
Facilities running Google Ads without Enhanced Conversions produce measurement gaps that get worse over time as third-party cookies phase out and client-side pixel accuracy continues to degrade.
GA4 as the cross-channel measurement layer
GA4 is not the source of truth for conversion signal. GA4 is the cross-channel measurement layer that tells you which channels are producing which conversions. The source of truth is always the CRM.
The specific configuration that makes GA4 work in a HIPAA-safe stack.
Custom events for each value tier. GA4 receives custom conversion events (vob_completed, admit_scheduled, admit_arrived, qualified_inquiry) via the server-side container. Each event carries the value field. The events fire from server-side, not client-side, which keeps PHI out of the GA4 pixel.
No PHI in event parameters. Event parameters can include the value tier, the source channel, and the campaign identifier. Event parameters cannot include the patient’s condition, the LOC they scheduled for, or any identifier that could de-anonymize the individual patient.
Custom dimensions for source attribution. GA4 supports custom dimensions that carry source data (utm_source, utm_medium, utm_campaign) through to conversion events. Configure custom dimensions for the specific source attribution the facility uses in reporting. Without this configuration, GA4 conversion events lose source attribution beyond the first-touch session.
Server-side pageview. Client-side GA4 pageviews are acceptable for standard analytics use, but any pageview on a thank-you page, confirmation page, or PHI-adjacent URL should be routed through the server-side container to strip PHI before it reaches GA4.
The GA4 configuration is the layer where most facilities have the largest gap between what they think their measurement is telling them and what it actually is.
The double-counting problem
The measurement gap I see most often is that GA4 says 40 conversions came from organic and Google Ads says 60 came from paid, but the CRM only shows 45 total admits for the same period. The two attribution platforms are double-counting because the conversion event is defined differently in each, and nobody at the facility has reconciled the two definitions against the CRM as source of truth. The organic side and the paid side both look like they are winning until you add them up and the total is bigger than the actual admit count.
Trevor Gage, Director of Marketing
GTM Server-Side as the connecting tissue
GTM Server-Side is the platform that makes the full stack work. Without it, each platform runs its own client-side pixel and its own separate server-side integration, and the four platforms drift out of alignment within 60 days of configuration.
The specific role GTM Server-Side plays:
Single point of transmission for all four platforms. The CRM fires one webhook to the server-side container. The container transmits to Meta CAPI, Google Ads Conversion API, and GA4 in parallel with a single normalized payload. All four platforms receive the same conversion event data at the same time.
PHI stripping before transmission. The server-side container strips any PHI from the incoming CRM webhook before forwarding to the ad platforms. This is the technical safeguard that keeps PHI out of Meta, Google, and GA4 regardless of what the CRM sends.
Consent state enforcement. For facilities operating in jurisdictions with consent requirements (California, Colorado, several EU jurisdictions), the server-side container enforces consent state before transmitting. If the customer has not consented, the container blocks transmission to that specific platform.
Deduplication and event ID management. The container assigns a unique event ID to each conversion event and ensures the same ID is used across all four platforms, preventing double-counting.
Facilities running Meta CAPI, Google Enhanced Conversions, and GA4 as separate direct integrations without a server-side container produce the double-counting pattern Trevor described above. The container is the technical layer that prevents it.
The monthly reconciliation cadence
The single audit that catches signal drift before it produces AI Max or Advantage+ failure runs monthly.
Step 1: Pull the trailing 30-day conversion count from each platform. Meta reports X CAPI conversions. Google Ads reports Y Enhanced Conversions. GA4 reports Z custom events across the specific value tiers.
Step 2: Pull the trailing 30-day admit count from the CRM. By source channel, by value tier.
Step 3: Reconcile against the CRM as source of truth. The specific expectation: Meta-reported CAPI conversions should approximately equal the Meta-source Tier 1 admits in the CRM. Google-reported Enhanced Conversions should approximately equal the Google-source Tier 1 admits in the CRM. GA4 should approximately equal the total Tier 1 admits from measurable channels.
Step 4: Investigate any variance greater than 15 percent. Variance above 15 percent surfaces one of a specific set of failures: server-side container misconfiguration, CRM webhook not firing, value tier mis-assigned, source attribution lost between session and conversion, or deduplication failure between client-side and server-side.
Step 5: Document the reconciliation in the QBR reporting. Our marketing-admissions QBR playbook covers the specific reporting structure where this reconciliation lives.
Facilities that skip the monthly reconciliation typically discover signal drift 60 to 90 days after it starts, at which point the AI-optimized paid campaigns have already run against contaminated signal long enough to produce the specific failure patterns documented separately.
DO
- Route every conversion event through a BAA-covered GTM Server-Side container — it strips PHI before Meta, Google, or GA4 ever sees the payload.
- Assign explicit value fields to all four tiers (Tier 1 admit, Tier 2 VOB, Tier 3 scheduled, Tier 4 qualified inquiry) so AI Max and Advantage+ optimize toward Tier 1.
- Fire the CRM webhook as the single conversion trigger — one payload, four platform transmissions, one shared event_id for deduplication.
- Reconcile Meta CAPI, Google Enhanced Conversions, and GA4 counts against CRM admit counts every 30 days — investigate any variance greater than 15%.
- Sequence CRM + call tracking → VOB → EMR handoff → tracking stack — building the stack before the CRM is clean produces defensible transmission of contaminated signal.
DON’T
- Put PHI in URLs, query strings, or fragments (email in a thank-you URL is a reportable HIPAA incident regardless of downstream receipt).
- Rely on client-side Meta or Google pixels alone — iOS ATT and third-party cookie deprecation have collapsed pixel accuracy below optimization threshold.
- Upload customer match lists with unhashed emails or with any patient metadata (condition, LOC, admit date) attached to the identifier.
- Count form-fills, calls, and admits as one conversion event — that is signal contamination and it is why AI Max chases the cheapest form-fill.
- Skip the monthly reconciliation — signal drift surfaces 60-90 days after it starts, at which point the AI-optimized campaigns have already run against contaminated data.
Common failure modes across the stack
Six failure modes we see repeatedly at facilities trying to build the full stack without the specific configuration discipline it requires.
PHI in query strings. Thank-you page URLs carrying email addresses or patient identifiers in the query string. This is the single most common compliance incident. Fix: server-side redirect that strips query parameters before the pageview fires.
Value tiers unset. Conversion events transmitted with no value field, or with the same value field across all tiers. AI Max and Advantage+ then optimize toward volume of any conversion type. Fix: explicit value assignment per tier in the server-side container configuration.
Client-side pixel still active alongside server-side. Both firing simultaneously without deduplication, producing 2x reported conversions and confusing the algorithms. Fix: either disable the client-side pixel entirely or enforce event ID deduplication.
CRM webhook silently failing. The CRM fires the webhook, the server-side container returns a 500 error, and the failure is not logged anywhere. Conversions do not reach the ad platforms. Fix: alerting on webhook failures at the container layer.
Source attribution lost between session and conversion. The user clicked a Google Ads link, the CRM webhook fires but does not carry the source attribution, and the conversion gets attributed to direct or organic instead of paid. Fix: session ID handoff between the CRM and the server-side container.
Consent state not enforced. The container transmits to platforms even when the user has not consented. Fix: consent state check at the container layer before every transmission.
Score Your Own HIPAA Compliance Risk in 3 Minutes
The failure modes above are the taxonomy. But reading them in a list is not the same as scoring your own stack against them.
We built a short quiz that walks through the 10 most common HIPAA marketing compliance risks we see at treatment centers. Answer honestly — the point is to surface where PHI is leaking or exposure is building — and in 3 minutes you will see your top 3 compliance risks ranked by severity, with the specific data check that confirms each and the first move to close it.
This is not legal advice. It is a marketing-operations self-audit. If any of these risks are showing up at your center, the first move is usually a conversation with your compliance officer and a technical audit of your ad account before OCR notices.
Where the stack fits alongside AI-optimized campaigns
Meta Advantage+ and Google AI Max lean on conversion signal more than legacy campaign types do. The full HIPAA-safe stack is the precondition that makes those campaign types work in behavioral health.
Without the stack, AI Max produces the failure modes documented separately. Meta Advantage+ chases the cheapest form-fill it can find, which is usually the lowest-value inquiry the campaign is capable of producing. Reported CPA looks strong, CRM admit volume drops, and the specific 45-to-90-day disconnect pattern surfaces.
With the stack, the AI-optimized campaigns receive value-tier signal that tells them Tier 1 admits are worth 6 to 10 times what Tier 4 form-fills are worth. The algorithms then optimize toward Tier 1 admits, which is what the facility is actually trying to buy.
The stack is the load-bearing infrastructure. The campaigns are the layer on top.
Facilities that invest in AI-optimized campaigns without the stack produce the specific failure pattern where the campaigns underperform legacy Standard Search and Meta Sales campaigns, at which point the operator concludes AI-optimized campaigns do not work in BH. They work. The stack has to be defensible first.
Frequently Asked Questions
Does our CRM automatically send conversion events to Meta and Google, or do we need to configure that?
You need to configure it. Most treatment center CRMs (Kipu CRM, Salesforce, HubSpot, Sunwave CRM) do not send conversion events to advertising platforms out of the box. The CRM has to be configured to fire webhooks to a server-side container, and the container has to be configured to transmit to Meta CAPI and Google Enhanced Conversions.
The specific setup varies by CRM. Salesforce and HubSpot have native webhook capabilities. Kipu CRM webhooks are configurable through the platform’s API. Sunwave CRM webhooks require middleware in some configurations. Our CRM migration piece walks the CRM-side considerations.
Facilities running CRMs without webhook capabilities cannot participate in server-side conversion tracking without middleware, which adds complexity and cost. This is one of the CRM-selection factors that matter for facilities considering a platform migration.
Can we run the stack without GTM Server-Side?
Technically yes, practically no. Running Meta CAPI and Google Enhanced Conversions as separate direct integrations without a connecting server-side layer produces the specific double-counting pattern Trevor described in the pull quote above. The four platforms drift out of alignment within 60 days.
Facilities without GTM Server-Side that want to run the full stack should invest in a server-side container as the first configuration step. GTM Server-Side is the standard because Google supports it directly and the configuration is documented. Custom Node servers work but require ongoing engineering investment most treatment centers should not carry.
The one exception is very small facilities running Meta only or Google only. For those cases, direct platform integrations are acceptable, but the growth path assumes the server-side layer gets added when the second platform activates.
How much does the full stack cost to build?
The specific cost varies with the facility’s existing infrastructure. For a facility with a working CRM but no server-side tracking layer, the build cost is typically $8,000 to $18,000 in one-time setup work plus $200 to $500 per month in ongoing container hosting and maintenance costs.
The build is not fast. The specific timeline is typically 6 to 10 weeks from decision to reconciliation-clean stack. Weeks 1-2 GTM Server-Side deployment; weeks 3-4 CRM webhook configuration; weeks 5-6 Meta CAPI and Google Enhanced Conversions integration; weeks 7-8 GA4 event schema; weeks 9-10 reconciliation verification.
Facilities that try to accelerate the timeline typically end up with configuration errors that surface as signal drift 60 to 90 days after launch, at which point the fix costs more than the deliberate 6-to-10-week build would have.
What happens if a patient’s email leaks into a query string on the thank-you page?
That is a HIPAA incident. The specific severity depends on how many analytics platforms received the URL, whether the email was hashed or plaintext, and whether the URL was cached anywhere downstream. Even with no downstream sharing, the incident is reportable under HIPAA breach notification rules if the leak involved unsecured PHI. Our HIPAA-compliant Facebook ads piece walks the incident-response framework.
The fix is a server-side redirect that strips query parameters before any pageview or event fires. The pattern: the form submission redirects to /thank-you?email=patient@example.com, the server sees the incoming URL, redirects immediately to /thank-you with no parameters, and only then does the pageview fire on the clean URL.
Facilities that discover PHI in query strings should treat it as a compliance incident regardless of whether the leak was actually received by a specific platform. Notify legal counsel and document the remediation. Adding the fix without documenting the incident is a bigger problem than the original leak.
How does the stack interact with the admissions ops software stack?
The conversion tracking stack lives inside the attribution + analytics category of the admissions ops software stack. It is Category 5 in that map.
The specific dependency is that the CRM (Category 1 in the stack map) has to be configured to fire webhooks with clean lead source attribution and value-tier data. If the CRM does not have those fields configured, the conversion tracking stack has no defensible signal to transmit to Meta and Google regardless of how well the tracking stack itself is configured.
The right sequencing for facilities under-invested across the whole operational stack is CRM and call tracking first, then VOB automation, then EMR integration audit, then conversion tracking + attribution. Skipping to the conversion tracking work before the CRM is clean produces a technically defensible stack that transmits contaminated signal.
Do we still need this stack if we do not run Meta or Google Ads?
Yes, if the facility runs any organic acquisition or referral marketing. GA4 is the cross-channel measurement layer that measures organic search performance, referral partner performance, and any other non-paid acquisition channel. Without GA4 configured with value-tier events, the facility has no defensible way to measure whether its organic content is producing admits. Our get-cited-in-AI-search framework covers the organic-side citation KPI construction.
The specific reduction for organic-only facilities: skip the Meta CAPI and Google Enhanced Conversions steps, keep the GTM Server-Side container, keep the CRM-to-container webhook, keep the GA4 configuration with value-tier events. Total build cost drops by 30 to 40 percent because the ad platform integrations are the largest configuration line items.
The YouTube AEO piece and the AI Information page piece both assume some version of the measurement layer exists so the facility can track whether the AI-readability surfaces are producing citation lift. GA4 with value-tier events is the measurement layer that makes that possible.
Keaton Nalle is the Director of Paid Admissions at Webserv, a digital marketing agency for treatment centers.
