Retail Partner Funnel

Overview

Project Origins

This case study documents the design and implementation of a multi-location acquisition and attribution system built for a financial services retail network. Certain branding, naming, and identifying details have been anonymized for confidentiality.

System validation was confirmed through cross-source consistency between event tracking, CRM ingestion, and routing resolution.

The project began as an initiative to modernize and centralize the credit application flow across multiple retail partner locations. Each storefront previously operated with isolated application forms, resulting in fragmented data collection and inconsistent attribution.

The resulting architecture introduced the company's first shared acquisition layer capable of supporting dozens of retail locations through a single application experience.

System Flow

Customers initiated the application process by scanning a QR code displayed at participating retail locations. Each QR encoded a unique combination of partner and location identifiers, allowing every visit to carry its origin from the very first interaction.

Upon arrival, a lightweight landing page extracted these parameters and dynamically injected them into the embedded application before submission. This allowed every completed application to be automatically associated with the correct retail partner and physical location without requiring manual selection or intervention.

Beyond simplifying the customer experience, this architecture established a reliable attribution layer while preserving the existing Zoho Forms to CRM integration, minimizing implementation effort and accelerating deployment.

Design Legacy

While initially scoped as a standalone implementation for a single sub-brand, this project introduced reusable patterns in attribution modeling, routing logic, and lightweight frontend architecture that continued to inform subsequent acquisition systems. These ideas were later refined and expanded in projects such as CLEX (see case study).

The Problem

The First Scalability Challenge

The existing acquisition process worked well while retail partners operated one or two locations. Attribution was achieved by assigning a dedicated application form to each partner, making the origin of every lead easy to identify.

That model stopped scaling when a new retail partner joined with more than 70 physical locations. A single partner was no longer enough to identify where an application originated, yet creating and maintaining a separate form for every store would dramatically increase operational complexity. The challenge was not collecting more applications. It was preventing operational complexity from growing alongside the retail network.

    "anh": {
      partner: "auto-international-insurance-agency",
      location: "Anaheim",
    },

    "apv": {
      partner: "auto-international-insurance-agency",
      location: "Apple Valley",
    },

     "bak": {
      partner: "auto-international-insurance-agency",
      location: "Bakersfield",
    },

     "bfl": {
      partner: "auto-international-insurance-agency",
      location: "Bakersfield 2",
    },

Initial Constraints

Rather than replacing the existing application pipeline, the objective was to extend it with minimal disruption. The solution needed to preserve the existing Zoho Forms to CRM integration while introducing reliable partner and location attribution across a growing retail network.

Taken together, these constraints reframed the challenge. The goal was no longer to build a new application, but to introduce the smallest possible architectural layer capable of making the existing system scalable.

The Solution

A Lightweight Architecture

Rather than replacing the existing application infrastructure, the solution introduced a lightweight layer around it. This approach preserved the native Zoho Forms to CRM integration while adding routing, attribution, and analytics without requiring backend development.

Dynamic Attribution

Partner and location information was carried through URL parameters generated by the routing layer. Upon loading the application, these values were automatically injected into the embedded form, allowing every submission to retain its originating retail context.

  const routes = {
    "wgt": {
      partner: "auto-international-insurance-agency",
      location: "Wilmington",
    },
  }; 

  const path = window.location.pathname.replace("/r/", "").toLowerCase();

  const route = routes[path];

  if (route) {
    const url = `/?partner=${route.partner}&location=${encodeURIComponent(route.location)}`;
    window.location.replace(url);
  } else {
    window.location.replace("/");
  }
  

Progressive Application Experience

Instead of loading the application immediately, the interface presented a lightweight introductory layer. Selecting "Start Application" recorded the beginning of the funnel before dynamically loading the embedded form, improving perceived performance while enabling more accurate behavioral measurement.

Analytics Integration

Key interactions were instrumented with custom GA4 events, providing visibility into application intent, progression, and completion. This transformed a previously opaque acquisition flow into a measurable funnel without modifying the underlying CRM integration.

The objective was not to replace the existing platform, but to extend it through a lightweight frontend layer capable of solving attribution and routing while preserving the existing backend workflow.

Technical Architecture

This layered approach kept each component focused on a single responsibility, making the system easier to maintain, extend, and scale as additional retail partners were introduced.

Operational Impact

Production Validation

Production deployment confirmed that a single application experience could reliably support a distributed retail network without sacrificing attribution accuracy or operational simplicity.

Lessons Learned

What initially appeared to be a one-off implementation became an exercise in designing for future growth. Introducing routing, dynamic attribution, and a centralized application flow. This project changed the way I think about scalability. The challenge was never building a more sophisticated application, but introducing the smallest architectural layer capable of removing an operational bottleneck. That principle later became the foundation for larger acquisition systems like CLEX.