Internal troubleshooting session between Melissa Cusumano and Mark Hope resolving three active issues for the [1] account: HubSpot form data visibility confusion, a stalled CallRail→GA4 integration, and broken dynamic number swapping on the website.
Attendees: Melissa Cusumano, Mark Hope
Duration: ~35 minutes
Problem: The Bluepoint client (Wade) reported that initial form submission data was not visible when opening a new contact record in HubSpot. He believed form fills were not being captured.
Root Cause: User expectation mismatch. The client was looking at the Overview tab, which is a summary panel — not a full activity log.
Resolution: Form submission data is correctly captured and lives in the Activity tab of the contact record. The Activity tab is the chronological record of all interactions: form fills, emails, calls, and page views. The Overview and side columns show contact properties and associated objects (deals, companies), not interaction history.
Verification: Confirmed by navigating to an existing contact (Tara Lynn) → Activity tab → Form Submission entry was present.
Action: Melissa will record a Loom walkthrough for the client explaining where to find form data and how HubSpot activity tracking works.
See also: [2] (if created)
Problem: The CallRail integration with Google Analytics 4 was stuck in "pending" status. CallRail flagged that multiple GA4 IDs were detected on the website and asked to validate the correct one.
Root Cause: Two issues:
1. An incorrect Measurement ID had been entered in CallRail (a TC9K... ID instead of the correct one).
2. The GA4 API Secret had not been provided.
Resolution:
1. Measurement ID — Corrected to G-THF..., found in GA4 under Admin → Data Streams → [stream] → Measurement ID.
2. API Secret — Retrieved from GA4 under Admin → Data Streams → [stream] → Measurement Protocol API Secrets, then entered into CallRail.
Configuration applied:
- Calls and SMS each set to send as a single custom event type
- Event value set to $1 per call/SMS — this makes the GA4 "value" field function as a simple lead counter rather than representing actual revenue
- Integration status changed to Active after saving
To find the API Secret in GA4: Admin → Data Streams → select stream → scroll to "Measurement Protocol API secrets"
Problem: The dynamic number swap for the banner phone number (720-...) was not working. The site continued to display the original number rather than swapping to a CallRail tracking number.
Diagnosis: The site was using the CallRail WordPress plugin to inject the tracking script. The plugin was identified as unreliable — it was either not loading correctly or conflicting with the site in a way that prevented the swap from functioning.
Resolution:
1. Deactivated the CallRail WordPress plugin (AB Call Rail Phone Tracking)
2. Added the CallRail JavaScript snippet directly to the site header via a code snippet manager (added as a new snippet named "CallRail", type JavaScript, location: header)
3. Confirmed the snippet ends in ...7856, matching the account's JS snippet
Verification: Tested in an incognito window (required because CallRail uses a cookie to avoid re-swapping numbers for returning visitors). Initial test showed a conflict while the plugin was still active; after deactivation, the swap was expected to function correctly once the site cache cleared.
Remaining step: Mark to clear the site cache to ensure the old cached number is flushed and the new snippet propagates.
Rule of thumb: Always use the direct JS snippet rather than the CallRail WordPress plugin. The plugin is unreliable. See [3] (if created)
720-... banner number is the primary swap target; it may also appear on the contact form page