DealerSight

Dealers know what they sold, not who almost bought. DealerSight turns Ring camera events into an anonymous showroom funnel, so you can see where visits and test drives stop turning into sales.

Comment

DealerSight: Understanding the dealership journey before a sale

Inspiration

The idea for DealerSight came from my internship in the financial-services division of an automotive company. During that experience, I learned more about how car manufacturers, dealerships, and captive-finance teams work together. Dealerships are not just places where cars are sold, they are a major part of how automotive companies reach customers, understand demand, and generate revenue.

I started thinking about how much information is available after a sale compared with how little is known about what happens before it. A dealership can see how many vehicles it sold or financed, but it may not know how many people visited, spent time looking at vehicles, or appeared to take a test drive. If sales fall, it can be difficult to tell whether the problem was low traffic, weak engagement, or customers leaving after a test drive.

That became the motivation for DealerSight: create an anonymous physical sales funnel that helps dealerships, manufacturers, and finance teams understand where customer activity may not be turning into business results.

I also wanted the project to be honest about what its data could and could not prove. DealerSight measures activity, not identity. It does not use facial recognition, follow individual customers, make credit decisions, or claim that a camera event proves someone intended to buy a car.

What it does

DealerSight turns Ring camera events into a five-stage dealership funnel:

  1. Visits
  2. Vehicle-area engagements
  3. Probable test-drive sessions
  4. Vehicle sales
  5. Captive-finance deals

The first three stages are inferred from Ring activity and camera placement. For example:

  • Activity at an entrance can contribute to a visit.
  • Activity lasting at least 20 seconds in a vehicle display area can become an engagement signal.
  • A departure-lane event followed by a return-lane event within a configured time window can become a probable test-drive session.

These are operational signals, not claims about a specific person. A probable test-drive session is called “probable” because DealerSight cannot anonymously confirm that the same vehicle returned.

The final two stages—sales and finance deals—use clearly labelled simulated business records because Ring cannot observe a completed sale or financing agreement. The historical Ring-shaped baseline is also labelled as simulated, while events retrieved from the Ring Developer Playground are labelled Live Ring.

DealerSight presents the funnel through three views:

  • The dealer view shows one dealership’s funnel, hourly activity, conversion rates, and findings worth investigating.
  • The manufacturer view compares dealerships and regions using aggregates only.
  • The captive-finance view compares the complete funnel before and during a simulated financing promotion.

Every figure shows where it came from. Live Ring events, rule-based inferences, simulated history, simulated business records, and AI-generated explanations have separate labels. A user can also open a funnel stage to see the records and rule version behind the number.

How I built it

DealerSight uses a FastAPI backend, PostgreSQL running through Docker, and a custom frontend designed to make the project’s evidence and limitations visible.

The live event path begins with the Ring Partner API. The application polls Ring Event History for new events, validates them, checks whether they have already been processed, and stores them using their unique Ring event IDs.

DealerSight can then process an event directly or route it through Amazon SQS:

Ring Playground
    → Ring Partner API
    → DealerSight poller
    → Amazon SQS
    → DealerSight worker
    → PostgreSQL
    → Funnel rules
    → Dashboard

SQS separates polling from event processing. Messages are deleted only after the database transaction succeeds, so a failed ingest can be retried. Duplicate deliveries are safe because the Ring event ID has a unique database constraint. Events that repeatedly fail can be moved to a dead-letter queue.

The funnel rules are stored in config/rules.yaml instead of being hidden inside the interface. Derived results are rebuilt from the stored events in timestamp order, which makes duplicates, replays, and out-of-order arrivals less likely to change the result.

For the AI analyst, I used Amazon Bedrock with Amazon Nova Pro. However, Bedrock does not calculate the metrics. DealerSight first computes a structured metric packet containing the completed counts, rates, changes, time periods, sources, and caveats. Bedrock receives that packet and explains it.

The model’s response is then checked against the packet. Each claim must reference a real metric and match its value, unit, direction, period, and scope. If the model contradicts the data, invents a number, stops unexpectedly, or becomes unavailable, DealerSight rejects the response and displays a clearly labelled deterministic fallback.

I also added a Check this finding feature. Because probable test drives depend on a matching window, DealerSight reruns the rule under strict, standard, and generous timing assumptions. It reports whether the finding remains supported or changes when the assumption changes.

Challenges I faced

The biggest challenge was that the Ring Developer Playground did not behave the way I initially expected.

The Playground provides Motion, Vehicle, and Package triggers, but all three appeared in Event History as the same on_demand event type with no classification. The videos were also the same, so DealerSight could not determine which button had been selected. The Playground exposes only one synthetic device, while my design required activity from multiple dealership locations.

I solved this by basing each rule on the camera’s configured placement instead of claiming Ring had classified what the camera saw. In a real dealership, a camera would have a fixed location. For the demo, the operator temporarily assigns the Playground camera to one of four positions:

  • Entrance
  • Vehicle Display Area
  • Lot Departure Lane
  • Lot Return Lane

The event ID, start time, end time, and duration still come from Ring. Only the camera position is supplied through the clearly labelled demo control.

Another challenge was that Playground tokens do not provide a documented way to test Ring webhooks. Instead, DealerSight uses Event History polling, which Ring documents as an alternative. The poller rescans a bounded overlap period so an event that appears late can still be found, and unique event IDs prevent that overlap from creating duplicate metrics.

Bedrock created a different challenge. During my first test, the model was given almost no information and invented a description of DealerSight. That showed me that a convincing answer is not necessarily a grounded answer. This experience led to one of the project’s main principles:

DealerSight calculates; Bedrock explains.

The model never receives responsibility for arithmetic, selecting the finding, or deciding whether the evidence supports the question.

What I learned

This project taught me that working around a limitation does not mean hiding it. The Ring Playground’s one-device limit and identical events changed the architecture, but documenting those constraints resulted in a more honest design based on camera placement and visible provenance.

I also learned that AI safeguards need to exist in application code, not only in a prompt. Even with temperature set to zero and detailed instructions, model responses can vary or misunderstand a metric. Structured packets, claim-level validation, deterministic fallbacks, and audit logs made the analyst much more dependable.

Finally, I learned how important failure handling is in an event-driven system. Adding SQS was not just about using another AWS service. It forced me to think about duplicate delivery, transaction boundaries, retries, malformed messages, unavailable services, and dead-letter monitoring.

Accomplishments I am proud of

I am proud that a real Ring Playground event can move through the application and visibly change the live dealership funnel. The dashboard never presents simulated history as Ring-originated and never presents an inference as an observation.

I am also proud of the project’s approach to AI. One of my favorite demonstrations is asking why a dealership’s conversion declined when its data shows that it did not. Instead of accepting the question’s premise, the analyst states that the decline is not supported.

DealerSight currently includes 129 tests and a six-scenario evaluation covering steady activity, missing data, ambiguous test-drive pairing, contradictory model output, and Bedrock being unavailable. The evaluation uses transactions that are rolled back, so it can run without changing the live demonstration data.

What is next

The next step would be testing DealerSight with several eligible Ring devices in fixed dealership positions. That would remove the need for the Playground assignment control and allow each location to produce activity independently.

I would also add registered-app webhook ingestion once it can be tested with real hardware, then connect the final funnel stages to properly anonymized dealership sales and finance systems instead of simulated records.

The long-term goal is not to monitor individual customers. It is to give dealerships and automotive companies a clearer, privacy-conscious understanding of where business activity is being lost—and where they should investigate next.

Built With

Share this project:

Updates

Submission history