Two briefs came in within days of each other from the same client segment: early-stage B2B SaaS, real estate analytics vertical, pre-launch infrastructure builds. One asked for a HubSpot specialist to configure a full sales infrastructure — 25,000 company records, tiered lead scoring, 15-territory routing, SLA automation, pipeline stages, dedup logic, and manager dashboards. The other asked for an analytics specialist to establish the foundational tracking stack — GA4, Google Tag Manager, Microsoft Clarity, HubSpot CRM integration, UTM framework, and event architecture recommendations. Both were scoped as standalone engagements. They're not. They're two layers of the same system, and building them independently produces two sets of siloed data that can't talk to each other. This is the full build — both layers, integrated, sequenced correctly.
The business context: a real estate analytics platform selling data intelligence to commercial property operators, investment groups, and institutional buyers. The product is still actively evolving — pricing not finalized, some conversion flows incomplete. That context is not a problem. It is the correct moment to build this infrastructure. The analytics foundation needs to capture data from the first visitor, not from launch day. The HubSpot configuration needs to be working before the first outbound sequence fires. Every day of delay is untracked pipeline and unattributed revenue.
Most early-stage SaaS companies split these into separate engagements because they appear to serve different teams. Analytics is a "marketing" or "product" function. CRM is a "sales" function. That split produces a predictable failure: the marketing team knows which campaigns are driving traffic but not which campaigns are driving closed deals. The sales team knows which leads converted but not where they came from or what they did on the product before booking a demo.
In a B2B SaaS company selling to commercial real estate operators, where deal cycles are 30–90 days and individual accounts can represent significant annual contract value, that attribution gap is expensive. A salesperson without session-to-signup behavioral data is having a different conversation than a salesperson who can see that the prospect visited the pricing page three times, downloaded the ROI calculator, and attended a webinar before filling out the demo form.
The integration point is the HubSpot contact record. Every GA4 event, every GTM trigger, every Clarity session heatmap is only as valuable as the connection back to a named contact in the CRM. Build them together, with the data model designed for integration from day one, or rebuild them later when the gap becomes painful.
"The analytics stack and the CRM are not two systems. They're the front end and the back end of the same revenue engine. Build them as one or spend 18 months reconciling data that should have been connected from the start." Arsalan Faysal — Revenue Systems Architect
The brief specifies a bulk import of 15,000–25,000 company records from external CSVs, with a monthly refresh of approximately 500 new additions and 150 removals. Before a single record is imported, three decisions must be made — in order — because each one determines how the next one is configured.
Decision 1: Company record as the primary object, not contact. In a B2B real estate analytics context, the prospect is an organization — a property group, an investment firm, a commercial operator. Individual contacts at that organization are secondary. HubSpot's company object should be the center of gravity for this build. Leads get scored at the company level. Territories are assigned at the company level. SLAs track at the company level. This is different from a typical HubSpot setup where contacts are the primary object. Reversing this later is expensive.
Decision 2: The unique identifier for deduplication. The brief specifies dedup logic against the existing partner base and prior contacted history. Before importing 25,000 records, establish the dedup key. For commercial real estate companies, the most reliable unique identifier is typically a combination of: company domain name (for organizations with websites) and geographic identifier (district + location type). A commercial property group with 12 regional offices will have one parent domain but multiple locations — the parent-group flag in the brief's scoring framework handles this case.
Decision 3: The import file structure. HubSpot's bulk import has a 250,000-row ceiling per file and processes at approximately 20,000 records per hour. For 25,000 records, this is a single import file. The file structure must include every property that will be populated on import — not just the properties that exist today. Adding properties to existing records post-import via a second import is possible but doubles the data entry risk and import validation overhead.
COMPANY RECORD IMPORT FILE STRUCTURE ────────────────────────────────────────────────────────────────── STANDARD HUBSPOT COMPANY FIELDS (mandatory for dedup) • Company Name (text) • Domain Name (text — primary dedup key) • City, State/Region, Country (geographic identity) • Phone, Website (contact data) • Number of Employees (firmographic) • Industry (select — pre-mapped to real estate sub-verticals) CUSTOM SCORING PROPERTIES (created before import) • Tier Score (number — calculated post-import by workflow) • Tier Classification (select — A / B / C / D) • Positive Score Drivers (multi-select — signals that increase score) • Negative Score Drivers (multi-select — signals that decrease score) • Geographic District (select — maps to territory assignment) • Location Type (select — HQ / Regional / Single-Site / Portfolio) • Parent Group Flag (boolean — is this record part of a larger group?) • Parent Group Name (text — name of the parent organization) • Data Source (select — which CSV batch / import run) • Import Batch ID (text — for refresh tracking and removal logic) ROUTING AND OWNERSHIP FIELDS • Territory Assignment (select — 1–15) • Assigned Salesperson (HubSpot Owner field) • First Import Date (date — set on initial import) • Last Refresh Date (date — updated on each monthly refresh) STATUS AND HISTORY FIELDS • HubSpot Partner Status (boolean — existing partner, exclude from outbound) • Prior Contact Date (date — when was this org last contacted?) • Prior Contact Outcome (select — No Response / Meeting Booked / Not Interested) • Current Lifecycle Stage (select — Lead / MQL / SQL / Opportunity / Customer)
The brief specifies 8–10 custom properties for a tiered scoring framework with positive and negative score drivers. Here is the full architecture.
The scoring model assigns a numerical score to each company record based on weighted positive and negative signals. The tier classification (A/B/C/D) is derived from that score. Both the raw score and the tier label are stored as HubSpot properties so that scoring logic can be audited, adjusted, and used independently in workflows and reports.
| Score Category | Signal Type | Example Signals | Point Weight |
|---|---|---|---|
| Portfolio Size Indicators | Positive | Manages 50+ properties, 100+ properties, 500+ properties | +10 / +20 / +35 |
| Asset Class Alignment | Positive | Commercial office, industrial, multi-family, retail — matches platform's coverage | +15 per aligned class |
| Geographic Market Fit | Positive | Operates in districts covered by platform's analytics data | +10 per district covered |
| Technology Sophistication Signal | Positive | Uses PropTech tools, has a dedicated analytics/BI team, known data buyer | +20 |
| Decision-Maker Accessibility | Positive | CEO / CFO / Head of Acquisitions has LinkedIn presence, direct contact available | +10 |
| Prior Engagement Signal | Positive | Attended webinar, downloaded content, visited pricing page | +25 |
| Existing Partner / Customer | Negative (exclude) | Already a paying customer or active partner — remove from outbound pool | –100 (effective disqualification) |
| Prior Hard Rejection | Negative | "Not interested" outcome logged in prior contact history | –40 |
| Data Quality Issues | Negative | No domain, no phone, no address — incomplete record | –20 |
| Geography Outside Coverage | Negative | All assets in districts not covered by platform data | –30 |
Tier classification thresholds map the numerical score to a letter grade:
These thresholds are configurable — they should be reviewed and calibrated after the first 90 days of outbound activity, once you have data on which tier classifications actually convert to meetings and which don't. The scoring model is a hypothesis at launch. It becomes calibrated over time when Closed Won/Lost data feeds back into the model.
In HubSpot, the score calculation is implemented as a Score property (a native HubSpot property type specifically designed for this purpose) combined with workflow-based property updates. The Score property auto-recalculates when any contributing property changes. The Tier Classification is set by a separate workflow that triggers on score range changes — this workflow updates the tier_classification select property and triggers downstream actions (routing, SLA start, notifications).
The brief specifies Tier A and B prospects auto-assigned to specific salespeople based on territory (10–15 territories, 10–15 salespeople). This is where the geographic_district property becomes the routing engine.
TERRITORY ROUTING LOGIC
──────────────────────────────────────────────────────────────────
TRIGGER: Company record tier_classification updated to A or B
(via scoring workflow)
ROUTING WORKFLOW:
Step 1: Check partner_status = false (exclude existing partners)
Step 2: Check prior_contact_outcome ≠ "Not Interested"
Step 3: Read geographic_district property value
Branch by district:
│
├── District 1 (e.g., Sydney CBD) → Assign Owner: Salesperson 1
├── District 2 (e.g., Melbourne CBD) → Assign Owner: Salesperson 2
├── District 3 (e.g., Brisbane Metro) → Assign Owner: Salesperson 3
├── District 4 (e.g., Perth Metro) → Assign Owner: Salesperson 4
├── Districts 5–8 (Regional East) → Assign Owner: Salesperson 5
├── Districts 9–11 (Regional West) → Assign Owner: Salesperson 6
├── Districts 12–13 (Interstate/NZ) → Assign Owner: Salesperson 7
└── [Continue for all 15 territories]
After assignment:
→ Create associated Deal record (Stage: New)
→ Set SLA start timestamp (sla_start_date = today)
→ Send internal notification to assigned salesperson
→ Create follow-up task with due date based on tier SLA
EXCEPTION HANDLING:
→ If geographic_district is empty: route to Round Robin (all territory owners)
→ If assigned salesperson is on leave (OOO flag): route to manager
→ If Tier A and salesperson has >25 open records: flag to manager
The territory-to-salesperson mapping is stored as a HubSpot workflow, not hardcoded in a Zap or external spreadsheet. This matters for maintenance: when a salesperson leaves or a territory is reassigned, you update one workflow — not a spreadsheet, not a Zap, not a CRM admin's institutional knowledge. The workflow is the source of truth.
The brief specifies six stages: New → Contacted → Meeting Booked → Meeting Held → Onboarded → First Transaction, with Lost available at any stage.
| Stage | Entry Trigger | Exit Criteria | Automation on Entry | SLA / Flag Rule |
|---|---|---|---|---|
| New | Tier A/B routing workflow creates deal | Salesperson logs first outreach attempt | Task created: "Make first contact" with SLA due date. Salesperson notified. | Tier A: 2 business days. Tier B: 5 business days. Auto-flag if overdue. |
| Contacted | Salesperson logs call/email outcome as "Connected" | Meeting scheduled OR second outreach logged | Task created: "Schedule discovery meeting." Deal last-activity timestamp updated. | Flag if no activity for 7 days (Tier A) / 14 days (Tier B). Auto-notify manager. |
| Meeting Booked | Calendar invite sent / Calendly booking confirmed | Meeting date passes (auto-advance trigger) | Confirmation sequence sent to prospect. Salesperson prep task created. | Flag if meeting not confirmed 24h before scheduled time. |
| Meeting Held | Meeting date passes + salesperson logs outcome | Proposal sent OR follow-up meeting booked | Post-meeting follow-up task created with 48h deadline. Deal notes required field prompt. | Flag if no outcome logged within 24h of meeting time. |
| Onboarded | Contract signed / subscription activated (manual trigger or webhook from billing) | First billing transaction confirmed | CS handoff task created. Welcome sequence enrolled. Deal moved to onboarding pipeline if separate. | Flag if no first transaction within 30 days of onboarding. |
| First Transaction | First billing event confirmed | N/A — deal closed Won | Deal closed Won. Revenue recorded. ARR property populated. Manager notification sent. | N/A |
| Lost (any stage) | Salesperson marks deal lost | N/A | Required: Loss reason logged (mandatory field). Company tier downgraded if hard rejection. Cooling period set on re-contact eligibility. | Loss reason is mandatory — deal cannot be marked Lost without a reason selected. |
SLA configuration is the most operationally impactful component of this build. Without it, the pipeline fills with deals that nobody is moving — technically open, functionally dead — and the conversion rate data becomes meaningless because the denominator includes records that were never genuinely being worked.
The SLA architecture operates at two levels: first-contact SLA (time from deal creation to first outreach logged) and activity SLA (maximum days of inactivity before the deal is flagged or reassigned).
The dedup requirement has two distinct use cases that need separate handling:
Use case 1: Import-time dedup. Before the 25,000-record CSV is imported, it must be cross-referenced against the existing HubSpot company database. The matching logic: domain name (primary), then company name + geography (secondary for records without domains). Any record that matches an existing company updates the existing record — it does not create a new one. Any record that matches a known partner gets the partner_status flag set to true, which prevents it from entering the routing workflow.
Use case 2: Monthly refresh dedup. The ~500 new records arriving monthly face the same dedup challenge at smaller scale. The monthly refresh workflow:
MONTHLY REFRESH WORKFLOW
──────────────────────────────────────────────────────────────────
INPUT: CSV with ~500 new records + ~150 removal identifiers
STEP 1: PRE-IMPORT DEDUP PASS
→ Match incoming records against existing HubSpot companies
by domain name (exact match) and company name + district
(fuzzy match threshold: 85% similarity)
→ Flag matches: "Update existing" vs "Create new"
→ Flag any matches against partner list: set partner_status = true
→ Output: clean import file with match status column
STEP 2: IMPORT EXECUTION
→ Import "Update existing" records as updates only
→ Import "Create new" records as new company creation
→ Set import_batch_id = [YYYY-MM] for all records in this run
→ Set last_refresh_date = today for all updated records
STEP 3: REMOVAL PROCESSING
→ For 150 removal records: do NOT delete (HubSpot deletions are irreversible)
→ Instead: set company_status = "Removed from Source"
→ Set active_prospect_flag = false
→ Remove from all active sequences and routing queues
→ Preserve all historical activity data on the record
STEP 4: SCORING RE-EVALUATION
→ Trigger scoring workflow re-run for all updated records
→ Any tier changes (upgrade or downgrade) trigger appropriate
routing or notification actions
The brief specifies dashboards covering: activity by salesperson, conversion by tier, time-in-stage, tier mix, onboarded vs target. Here are the seven reports that deliver those requirements, with specific HubSpot report types for each.
| Report Name | HubSpot Report Type | Primary Metric | Audience |
|---|---|---|---|
| Activity by Salesperson | Sales Activity Report (built-in) | Calls logged, emails sent, meetings booked, tasks completed — by owner, current week vs last week vs target | Sales Manager (daily) |
| Pipeline Funnel by Tier | Funnel Report — deals by stage | Deal count at each stage, filtered by tier_classification. Shows where Tier A deals are stacking versus Tier B. Conversion rate between each stage. | Sales Manager + Leadership (weekly) |
| Time-in-Stage Analysis | Deal Stage Duration Report (custom) | Average days in each stage, by tier and by salesperson. Identifies bottlenecks — if deals are stacking in Meeting Held, the follow-up process is broken. | Sales Manager (weekly) |
| SLA Compliance Dashboard | Custom report — deals with SLA breach flag | Deals past SLA threshold by tier. Overdue first-contact attempts. Stale deals by owner. Red/amber/green status indicators. | Sales Manager (daily — operational) |
| Tier Mix and Scoring Distribution | Company report — count by tier_classification | Total company records by tier (A/B/C/D). Trend over time as monthly refreshes add records. Distribution by territory. | Leadership (monthly) |
| Onboarded vs Target | Goal-based report — deals in Onboarded + First Transaction stages | Monthly onboarded count vs target. Revenue recognized vs target ARR. Comparison by territory and by tier source (which tier drove the most closed won?). | Leadership (monthly) |
| Lost Reasons Analysis | Deal report — lost_reason property breakdown | Count of Lost deals by reason. Identifies systemic problems: if "Price too high" is dominant, that's a pricing or tier-calibration problem. If "Not a good fit" dominates, the scoring model needs adjustment. | Leadership + Product (monthly) |
The analytics brief is correctly scoped for an early-stage company: foundational infrastructure now, detailed event tracking and conversion optimization once the product is finalized. This is the right sequencing. The risk is building too little now and having no historical data when the product launches, or building too much and wasting implementation time on tracking flows that will change completely when the pricing model is confirmed.
The correct approach: build the measurement foundation now (GA4 property, GTM container, Clarity, HubSpot integration, UTM framework) and define an event architecture that is designed to be extended — not replaced — when detailed conversion tracking is added at launch.
ANALYTICS STACK ARCHITECTURE
──────────────────────────────────────────────────────────────────
LAYER 1: TAG MANAGEMENT
Google Tag Manager (GTM)
→ Single container for all tracking scripts
→ All GA4 events, Clarity, LinkedIn Insight Tag, HubSpot
tracking code deployed through GTM
→ Never hardcode tracking scripts directly on the site
LAYER 2: BEHAVIORAL ANALYTICS
Google Analytics 4 (GA4)
→ Primary analytics platform
→ Event-based data model (replaces sessions/pageviews paradigm)
→ B2B SaaS-specific events configured (see event architecture below)
→ Connected to Google Search Console for organic search data
Microsoft Clarity
→ Session recordings and heatmaps
→ Complements GA4 quantitative data with qualitative UX insight
→ Automatically tags sessions with rage clicks, dead clicks,
excessive scrolling — early UX signal without setup overhead
→ Connected to GA4 via Clarity's native GA4 integration
(Clarity session data appears in GA4 custom dimensions)
LAYER 3: CRM INTEGRATION
HubSpot Tracking Code
→ Deployed via GTM (not hardcoded)
→ Captures anonymous visitor sessions and de-anonymizes
when contact submits form or clicks tracked link
→ UTM parameters from paid traffic preserved in contact
first-touch and last-touch source properties
→ HubSpot analytics and GA4 data cross-reference
via shared UTM parameter framework
LAYER 4: ATTRIBUTION
UTM Framework (see below)
→ Consistent UTM parameter structure across all traffic sources
→ Parameters captured in HubSpot contact properties
AND GA4 session source/medium dimensions
→ Enables closed-loop attribution: GA4 traffic → HubSpot
contact → Deal → Revenue
GA4's event-based model gives you flexibility that Universal Analytics didn't have. It also gives you the ability to instrument nothing meaningful and end up with a GA4 property full of pageviews and zero useful behavioral data. The event architecture for an early-stage B2B SaaS company in the real estate analytics space needs to be opinionated about what matters.
Three principles for the event architecture:
click_1) is worse than no event at all because it pollutes the data layer. Use snake_case, descriptive action-object naming: demo_form_started, pricing_page_viewed, roi_calculator_completed.| Event Name | Trigger | Key Parameters | Priority | GTM Implementation |
|---|---|---|---|---|
page_view |
Any page load | page_title, page_location, content_group (Blog/Product/Pricing/etc.) | P0 — Launch day | GA4 built-in (automatic) |
pricing_page_viewed |
Page view on /pricing (or pricing section) | page_section, scroll_depth_50, scroll_depth_90 | P0 — High intent signal | GTM trigger: Page Path contains /pricing |
demo_form_started |
First interaction with demo request form | form_id, form_location (hero/inline/exit) | P0 — Conversion funnel entry | GTM trigger: Form field focus on target form |
demo_form_submitted |
Demo form successful submission | form_id, company_size_selected, use_case_selected | P0 — Primary conversion event | GTM trigger: Form submission success callback |
content_download |
Download of report, guide, or data sample | content_title, content_type, gated (boolean) | P1 — Lead magnet tracking | GTM trigger: Link click to PDF / gated content URL |
feature_page_engaged |
30s+ time on product feature page + scroll to 50% | feature_name, time_on_page, scroll_depth | P1 — Product interest signal | GTM trigger: Timer + scroll depth combination |
outbound_link_click |
Click on external link (e.g., to partner site, case study PDF) | link_url, link_text, link_location | P1 | GA4 built-in (enhanced measurement) |
search_performed |
Site search query submitted | search_term, results_count | P1 — Intent signal (what are prospects looking for?) | GA4 built-in (enhanced measurement) |
login_completed |
Existing user login success | user_type (trial/paid), plan_name | P1 — Engagement baseline | GTM dataLayer push on auth success |
trial_signup_started |
Trial/signup flow entry | signup_source, plan_selected, referral_code | P0 — Once trial flow is live | GTM dataLayer push on flow entry |
trial_signup_completed |
Successful trial account creation | plan_name, company_size, industry_segment | P0 — Primary conversion (post-launch) | GTM dataLayer push on account creation confirmation |
plan_viewed |
View of specific pricing plan detail | plan_name, plan_price_tier | P1 — Post pricing launch | GTM trigger: Click or visibility on plan card |
Google Tag Manager is not just a tag container. In this build, GTM is the data orchestration layer — the system that ensures every tracking platform receives consistent, accurate data from a single implementation source. The architecture:
GTM CONTAINER STRUCTURE
──────────────────────────────────────────────────────────────────
VARIABLES (configured once, reused across all tags)
├── GA4 Measurement ID (constant variable)
├── HubSpot Portal ID (constant variable)
├── Clarity Project ID (constant variable)
├── DataLayer variables (for custom event parameters)
│ ├── dlv_event_name
│ ├── dlv_form_id
│ ├── dlv_content_title
│ ├── dlv_user_type
│ └── dlv_plan_name
└── URL variables
├── Page URL (built-in)
├── Page Path (built-in)
└── UTM parameters (custom JS variable reading URL params)
TRIGGERS
├── All Pages (pageview)
├── Pricing Page View (page path trigger)
├── Demo Form Focus (form field click trigger, form ID specific)
├── Demo Form Submit (form submission trigger)
├── Custom DataLayer Events (custom event trigger — catches all
│ dataLayer.push() calls from the application code)
├── PDF Link Clicks (link click trigger — URL contains .pdf)
├── Timer — 30 seconds on feature pages
└── Scroll Depth — 50% and 90% (scroll trigger)
TAGS
├── GA4 Configuration Tag (fires on All Pages)
│ └── Sends: page_view + user properties
├── GA4 Event Tags (one per custom event type)
│ └── Each tag fires on its specific trigger
│ └── Each tag sends event_name + relevant parameters
├── HubSpot Tracking Code (fires on All Pages)
├── Microsoft Clarity (fires on All Pages)
└── LinkedIn Insight Tag (fires on All Pages — if LinkedIn Ads used)
UTM parameters are the connective tissue between paid/organic traffic sources and the HubSpot contact records they eventually become. Without a consistent UTM structure, you have GA4 data saying "this traffic came from LinkedIn" and HubSpot data saying "this contact came from LinkedIn" but no reliable way to connect which LinkedIn sessions generated which contacts which generated which deals.
| UTM Parameter | Purpose | Convention / Example Values | Maps to HubSpot Property |
|---|---|---|---|
utm_source |
Traffic origin platform | linkedin, google, email, referral, direct |
hs_analytics_source |
utm_medium |
Traffic channel type | cpc, organic, email, social, content |
hs_analytics_source_data_1 |
utm_campaign |
Campaign name | Use consistent naming: realestate_awareness_q1_2025 — not "Campaign 1" |
hs_analytics_source_data_2 |
utm_content |
Creative variant / ad content ID | carousel_v1, video_testimonial, whitepaper_cta |
Custom property: hs_utm_content |
utm_term |
Keyword (paid search) | Keyword string from paid search | Custom property: hs_utm_term |
In HubSpot, configure the Original Source, Original Source Drill-Down 1, and Original Source Drill-Down 2 properties to capture first-touch UTM values when a contact is created. Also create custom properties for Last Touch Source, Last Touch Medium, and Last Touch Campaign — populated by a workflow that fires on every conversion event and stamps the current UTM values. This gives you both first-touch and last-touch attribution without a separate attribution tool.
Clarity is a free heatmap and session recording tool that provides qualitative behavioral data to complement GA4's quantitative metrics. For an early-stage SaaS with an evolving product and unfinished conversion flows, Clarity's automatic rage-click and dead-click detection is particularly valuable — it identifies UX friction points that GA4 event tracking won't capture because they happen on flows that aren't yet instrumented.
Configuration steps specific to this build:
clarity_session_id as a custom dimension to GA4 for every Clarity session. You can then segment GA4 behavioral data by Clarity session recordings — clicking through from a GA4 funnel drop-off to the actual session recording of that user.The integration between HubSpot and GA4 is not native — HubSpot and Google Analytics are separate platforms with separate data models. The connection is built at three points:
Point 1: UTM parameter preservation in HubSpot. When a visitor arrives via a UTM-tagged URL and converts (submits a form, clicks a tracked link), HubSpot's tracking code captures the UTM parameters from the URL and stores them against the contact record. This works automatically once the HubSpot tracking code is deployed via GTM and forms are configured correctly — no additional setup required beyond the UTM framework above.
Point 2: GA4 Custom Dimensions for HubSpot contact data. When a visitor who is a known HubSpot contact (has been cookied by HubSpot and has a contact record) visits the site, push their HubSpot Lifecycle Stage and HubSpot Contact Owner as GA4 user properties via a GTM tag. This allows you to segment GA4 behavioral data by CRM stage — "what pages are MQL-stage contacts visiting before they become SQLs?" is a question you can now answer.
Point 3: GA4 Conversions → HubSpot Deals. When the primary GA4 conversion event fires (demo_form_submitted), a HubSpot workflow should simultaneously receive the form submission data and create/update the contact record, create a deal at Stage: New, and trigger the tier scoring evaluation. The GA4 event and the HubSpot deal creation are the same moment in time — they reference the same form submission. The integration point is the form itself.
The two briefs represent one integrated engagement. The sequencing matters — analytics infrastructure before the CRM build means the HubSpot tracking code and UTM framework are capturing data during the CRM configuration work, which is valuable for testing. CRM architecture decisions (especially the company object structure and scoring properties) need to be finalized before any import happens.
| Phase | Work | Hours | Output |
|---|---|---|---|
| Phase 1 — Week 1 | GA4 property setup. GTM container build. HubSpot tracking code via GTM. Clarity setup and GA4 connection. UTM framework documentation. P0 event tags (page_view, pricing_page_viewed, demo_form_submitted). | 12–16h | Analytics foundation live and collecting data. Verification in GA4 DebugView + GTM Preview confirmed. |
| Phase 2 — Week 1–2 | HubSpot company object architecture. Custom property creation (all 10 scoring + routing properties). Association configuration. Scoring model configuration. Territory routing workflow build. | 10–14h | HubSpot property schema complete. Scoring workflow live in sandbox. Territory routing logic documented and built. |
| Phase 3 — Week 2 | Import file preparation and dedup logic. Partner list cross-reference. Import execution (25,000 records). Post-import validation. Scoring workflow run on imported records. Initial tier distribution report. | 10–14h | All company records in HubSpot, scored, tiered, and territory-assigned. Import validation report delivered. |
| Phase 4 — Week 2–3 | Pipeline configuration (all 6 stages + Lost). Stage-transition automations. SLA workflow build. Stale lead flagging and reassignment logic. Deal creation on tier A/B routing. | 10–12h | Pipeline operational. SLA rules live. First deals created from Tier A/B records. |
| Phase 5 — Week 3 | P1 GA4 event tags (content_download, feature_page_engaged, login_completed). GA4 custom dimensions for HubSpot lifecycle stage. Clarity session segments. Monthly refresh workflow build. | 8–10h | Full P0 + P1 event tracking live. Clarity segments configured. Refresh workflow tested. |
| Phase 6 — Week 3–4 | Manager dashboards (all 7 reports). KPI dashboard in GA4 + HubSpot. Looker Studio report connecting GA4 + HubSpot data (optional). UTM tracking verification across paid channels. | 8–10h | Dashboards live. Management reporting operational. |
| Phase 7 — Week 4 | Training sessions (2 × 1.5h — sales team + management). Documentation deliverable (HubSpot admin guide, analytics spec, UTM naming convention guide, monthly refresh SOP). | 8–10h | Team trained. Documentation delivered. Engagement handoff complete. |
| Total | 66–86 hours | Full stack live, team trained, documentation delivered. |
The brief correctly anticipates a follow-on engagement after the product and pricing launch. The Phase 1 work described above makes Phase 2 dramatically faster because the data layer is already in place. Here is exactly what Phase 2 covers and why it cannot be built until Phase 1 is complete.
Once the trial flow, membership plans, and checkout flow are finalized, implement the P0 events that were deferred: trial_signup_started, trial_signup_completed, plan_viewed, checkout_started, purchase_completed. These events require the final URL structure and form architecture to exist before they can be implemented — which is why they are Phase 2, not Phase 1.
With the trial signup flow live and conversion events firing, build GA4 funnel exploration reports that show exactly where users are exiting the trial signup process. This is the primary conversion rate optimization input. It requires a minimum of 2–4 weeks of data collection post-launch before the funnel drop-off patterns are statistically meaningful.
A/B testing recommendations for a B2B SaaS at this stage: run experiments on the demo request CTA copy and placement (highest volume, fastest results), pricing page layout and plan presentation order, and trial onboarding email sequence timing. Do not run A/B tests on the core product positioning until the conversion baseline is established. Testing without a baseline is noise.
With 60+ days of session data post-launch, the GA4 path exploration reports and Clarity session recordings will identify the non-obvious paths that lead to trial signup or demo booking. Real estate analytics buyers are researchers — they often take unusual paths through the product documentation, case studies, and methodology pages before converting. Understanding that path is the basis for content strategy and ad targeting in the next phase of growth.
Early-stage SaaS companies consistently underinvest in their analytics and CRM infrastructure during the pre-launch window. The reasoning is understandable: the product is still changing, the pricing isn't finalized, the website is being rebuilt — why set up tracking now?
Because every day that passes without the GA4 property collecting data is historical data you will never have. When your first paid campaign launches, you will have no baseline to compare against. When your first 100 demo requests come in, you will not be able to attribute which traffic source drove the ones that converted to deals versus the ones that ghosted. When your sales team starts working the 25,000-record import, they will be working from a spreadsheet with no engagement data, no web behavior history, and no way to know which companies already visited the pricing page before the salesperson's first call.
The infrastructure described in this post takes four weeks to build. The data it starts collecting on day one compounds for as long as the business runs. There is no equivalent return on any other four-week investment a pre-launch SaaS can make.
Build the foundation now. Optimize the details later. The later never comes without the foundation.