How the engine works,
step by step.
One analytical engine, applied the same way to commercial research, public-opinion polling, and operational data. This page lays out the problem it solves, the four-step workflow it produces, the technical guts that make it credible, and how a single engagement runs from design to release.
Every research method speaks a different language.
And the senior insights leader is the one expected to make them speak together.
A large CPG company runs concept tests in one frame, conjoint in another, brand trackers in a third, copy tests in a fourth, pricing studies in a fifth, TURF and assortment studies in a sixth, panel data in a seventh. Each method has its own supplier, its own deliverable format, its own vocabulary, its own simulator if it has one at all. The reports sit in different decks, different software, different tabs in different spreadsheets.
When the senior insights leader is asked — by the CMO, by the brand team, by finance — to draw a coherent strategic picture from all of it, the work falls on internal teams to translate across methods after the fact, in PowerPoint, with no shared analytical structure underneath. The result is a synthesis that depends on whoever wrote the deck, with no mechanism for someone else to test or challenge it.
That is not a methodology problem inside any single research project. It is a structural problem at the level of the insights function. And it persists because the analytical layer that would unify these methods — explaining each finding in the same headline-driven, simulator-backed frame — has not existed as a routine deliverable.
Findings don't compose
Each method's results are reported in its own units, with its own software. There is no common structure that lets you ask the same question of all of them at once.
"Why did the number move?"
Trackers and concept scores show that something moved. Without a disciplined explanatory model behind each, the answer to "why?" is opinion, anecdote, or guesswork that doesn't carry weight in a senior conversation.
Reports nobody opens twice
A six-figure research project produces a PDF that gets read once and shelved. The brand team's actual decisions happen weeks later, against a question the report doesn't directly address.
One analytical engine. Every method. A common frame.
Electric Insights is the analytical engine that turns each research method's binary outcome into the same kind of headline-explained-and-simulatable structure. The insights function gets a single coherent vocabulary across all of its work.
Pick the headline
The yes/no the business is actually deciding against. Top-2 purchase intent. Chose-our-brand. Top-box brand fit. Recalled-the-ad. Renewed.
Build the explanation
A disclosed explanatory model fit on candidate drivers, with diagnostics and calibration reported alongside. The reasoning behind the headline is no longer commentary — it's part of the deliverable.
Translate to common units
Coefficients become percentage-point shifts in the headline. The output reads in the units the brand team already uses — in any method, identical structure across them.
Wrap it in a simulator
Every method's deliverable now ships with a tool the team can run after delivery: shift one driver, shift several, restrict to a subgroup, see what the headline becomes.
When this is done across every research method an organization runs, the insights function gains a structural capability it has never had before: the ability to read across methods in the same language.
The same engine, three buyer worlds
Electric Insights is data-agnostic. Wherever there is a binary outcome that matters — in commercial research, in public opinion, in operational and behavioral data — the engine produces the same headline-explained-and-simulatable deliverable. The data shape changes; the deliverable structure does not.
| Method or data source | Data shapes encountered | What Electric Insights produces from it |
|---|---|---|
| Commercial research Brand and insights teams at consumer-goods, retail, financial-services, and tech companies. The craft-beer concept test on this site is the live working example, built with anonymized data from a partnership with emi Research Solutions. | ||
| Concept tests | Survey microdata: rating scales, attribute responses, demographics | An explanatory model of top-2 purchase intent with predicted-margin reporting in points, and a simulator for testing package, claim, and feature changes. |
| Discrete-choice / conjoint | Choice-task records with respondent attributes and price levels | A model of chose-our-offer and the attribute-rating responses around the choice exercise, with a simulator for testing attribute combinations and segment differences. |
| MaxDiff | Best-worst trade-off data across competing claims or benefits | A model of which claims actually move choice when shown beside others, with a simulator for testing claim portfolios. |
| Pricing studies | Gabor-Granger or Van Westendorp survey responses, plus respondent attributes | A model of would-buy-at-this-price by segment, with a simulator for testing how price elasticity interacts with claim, package, or feature changes. |
| Brand tracking | Longitudinal tracker waves, market-by-market | A model of top-box brand fit, awareness, or consideration, with a simulator for testing which perceptions are doing the work and which are noise — including across markets. |
| Copy / ad testing | Pre/post exposure data, respondent attributes, creative variants | A model of recalled, liked, or persuaded, with a simulator for testing which creative elements drive the lift — in lift, not just in correlation. |
| Public-opinion research Polling organizations, civic and government researchers, academic survey programs. The 1963 Harris–Newsweek JFK case study on this site is the live working example, tied to a paper currently under peer review. | ||
| Approval and favorability tracking | Weighted survey samples, repeated waves | A model of approve/disapprove with a simulator for testing how the headline shifts under changes to specific evaluations — the JFK case-study deliverable, exactly. |
| Election and ballot research | Likely-voter samples, vote intention, candidate evaluations | A model of vote intention with a simulator for testing how horse-race and issue evaluations move it, including subgroup-conditional refits to see whether the same drivers operate within partisan, demographic, or geographic groups. |
| Issue and policy research | Issue-attitude batteries, policy-position scales, demographics | A model of support/oppose on the policy of interest, with a simulator for testing which framings, demographic factors, or ancillary attitudes move support. |
| Mixed-mode survey programs | Online, phone, address-based, and panel-based collections combined | An explanatory model that handles weighted samples and mode-effect adjustments, plus a nonresponse-sensitivity check that is the public-opinion-specific vulnerability test. |
| Operational, behavioral & event data Sports analytics teams, retail-analytics groups, customer-success and product organizations — anywhere the data is event-level rather than survey-based. The NBA 2014–15 shot-tracking case study on this site is the live working example. | ||
| Sports analytics | Event-level census data: every play, shot, or pitch, with context features | A model of make/miss (or score/no-score, win/loss), with a simulator for testing how outcome rates would change under shifts in the contextual factors. No sampling, no nonresponse to model. |
| Point-of-sale and transactional data | Transaction-level records with product, price, time, location, and customer attributes | A model of purchase/no-purchase or repurchase, with a simulator for testing how transaction rates change under price, promotion, location, or customer-segment shifts. |
| Customer-success and panel data | Longitudinal usage, engagement, and churn records | A model of renewed/repurchased/churned with a simulator for testing what separates retainers from churners and which moveable factors would shift the rate. |
| Sensor and behavioral logs | High-frequency time-series data, often paired with categorical context | A model of any binary event in the log — conversion, alert, fault, threshold-crossing — with a simulator for testing how the rate responds to changes in measured drivers. |
Three different worlds. The deliverable shape across all of them is structurally identical. That is what makes cross-method — and cross-domain — reading possible.
What's actually under the hood
A claim that one analytical engine can serve every research method is only credible if the engine is methodologically serious. Below is what the platform actually does — the work that makes the unifying claim work.
Modeling
-
Bespoke explanatory models per engagement Each engagement produces its own model, fit on the candidate drivers that matter for the question. Not a one-size template.
-
Subgroup-conditional refits Refit the same specification on a defined segment — Hispanic shoppers, Region 4, lapsed-buyers — and see the explanation shift, not just the score.
-
Cross-validated forward stepwise selection For users without strong priors, an Auto-Build path constructs a defensible specification by improvement on cross-validated Tjur R² with a strict minimum-improvement threshold.
-
Actionable-predictor mode A second Auto-Build path biases selection toward variables that can be moved by policy, communication, or product change — surfacing levers, not just correlates.
-
Continuous-predictor scenario semantics Native handling of continuous drivers — pin to a value, redistribute the population, raked weighting on the simulated frame — with truncation and binning rules disclosed.
Diagnostics & vulnerability
-
Calibration assessment Decile-level predicted-vs-observed gaps, with mean and max calibration gap reported per fit. Headline-unit reporting is only meaningful if the model is calibrated, and we show the test.
-
GVIF collinearity flagging Generalized variance inflation diagnostics (GVIF^(1/2df)) flag predictors whose joint variation is captured by others — alerting users that those coefficients are not interpretable as independent effects.
-
Variable-ranking diagnostic Of the variables in the questionnaire but not in the published model, which would most improve fit if added — and which would just duplicate predictors already there.
-
Synthetic-variable stress test User-specified hypothetical omitted factor, with declared correlation to the outcome and overlap with existing predictors. Tests how dependent the published interpretation is on what the questionnaire didn't capture.
-
Nonresponse sensitivity For sample-based studies, expresses the headline's sensitivity to assumptions about who didn't respond, benchmarked against the familiar margin of error.
Translation & reporting
-
Headline-unit predicted margins Every coefficient translated to a percentage-point shift in the headline. Two-sided 95% intervals on every estimate. Coefficients remain available for technical inspection but are never the headline.
-
Set-everyone-to-X scenarios Predicted percentages and PP changes for "set the whole sample to this response level," with thin-cell flagging where extrapolation is unsafe.
-
Population-redistribution scenarios Shift the population's distribution on a driver by a stated amount and see the simulated headline — the realistic operational counterpart to set-everyone-to-X.
-
Plain-language stability flags Thin cell, extreme weights, near-certain prediction, suppressed — surfaced in the scenario table where readers will see them, not buried in an appendix.
Validation
-
Validated against Stata 18 Coefficient estimates and robust standard errors match Stata's logit and pweighted GLM output to four decimal places on both unweighted and weighted test datasets, including in the smallest heterogeneous-weight subgroups.
-
Configuration-driven, not bespoke per study A new study requires its microdata, codebook, and per-study narrative content — not new modules. The engine is the same across engagements.
-
Tied to a peer-reviewed methodological framework The approach is documented in a paper currently under peer review at Public Opinion Quarterly, with the JFK case study as its formal proof-of-concept.
The unifying claim, working
Three case studies, on three radically different data shapes. A 1963 public-opinion survey. 2014–15 NBA shot-tracking data. A 2025 craft-beer concept test. Different data, different decades, different industries — and the same four-part deliverable: headline, explanation, vulnerability checks, simulator.
If the same engine produces structurally identical outputs across these three, it produces them across the seven research methods above.
JFK Approval, 1963
n=1,180 respondents. Six-variable explanatory model on a 57% approval headline. All five tools live, including the nonresponse sensitivity check that sample-based studies require.
View JFK Case StudyNBA 3-Point Shots
Every tracked three-point attempt in the 2014–15 season. Same explanatory layer, no sampling, no nonresponse to model. Same simulator structure as JFK and concept test.
View NBA Case StudyCraft-Beer Concept Test
n=803 beer-buying consumers. 47% top-2-box headline. Five tools live for the brand team to interrogate package perception, claim strength, and segment differences after delivery.
View Concept TestThe data shapes have nothing in common. A historical public-opinion survey, a fully-observed NBA shot log, and a commercial concept test. The deliverables are structurally identical. That is the unifying claim, made concrete.
What this isn't
The unifying claim is large enough that the boundaries deserve to be stated plainly.
Not a norms or benchmarks database
We don't tell you whether 47% top-2-box is good for your category. BASES, Nielsen, Kantar, and your tracker history do that. We model the data you have.
Not a volume forecast
Concept score to year-1 case volume is a different problem with different inputs. Keep your forecasting partner.
Not a sample provider
Fielding, recruiting, weighting, and quotas stay with your supplier. We work on the data they collect.
Not an assortment or TURF optimizer
TURF, line optimization, and reach-maximization across items are a combinatorial search problem, not an explanatory one. We model what drives a single headline; we don't search item-set space for the best lineup. But once you've chosen a lineup, reach is a binary — and we can explain who it reaches, like any other headline.
Suppliers produce the data. Norms tell you whether the score is good. Forecasting tells you what the score is worth in dollars. Assortment tools pick the best lineup. Electric Insights produces the explanation and the tool that makes the score actionable. These are different jobs and they all matter.
How a single engagement runs
Three stages, applied to whichever method the data came from. The decisive work happens before modeling begins, not after.
Design — before modeling begins
Most analytical workflows start once modeling starts. This one starts earlier. Before any model is fit, the project commits in writing to the outcome that will anchor the release, the bounded set of candidate drivers, and the rules for reporting results. For new research, Design also shapes what gets measured. For existing data, Design audits whether the recorded variables can support a disclosed explanatory account at all.
The Design specification covers:
- the outcome and how it will be operationalized
- the candidate driver set and how each is measured
- the scenario rules (what "holding other drivers constant" will mean)
- the interval routine for reported uncertainty
- which vulnerability checks apply, given the data's structure
This pre-commitment is what keeps explanation from arriving later as commentary rather than as part of the release itself.
Model — working with the data
With the data in hand, the candidate drivers compete. The analysis fits an explanatory model of the outcome, reports fit and calibration diagnostics, and translates results from coefficients into the outcome's own units — percentages, percentage-point shifts, probabilities, rates. Coefficients remain available for technical inspection but are never the headline.
Model stage deliverables:
- a named, disclosed explanatory model with documented diagnostics
- scenario estimates in outcome-level terms with two-sided intervals
- the vulnerability checks declared at Design: variable ranking, synthetic-variable stress test, and — for sample-based data — nonresponse sensitivity
Release — a coupled deliverable
The final deliverable is not a report that references a model, and not a dashboard without a model. It is a single coupled object — we call it a Mirror — that ships the score, the model in outcome units, the vulnerability checks, and the tools to inspect and challenge the analysis, together. For public-polling clients, the Mirror is published with the press release. For private clients, it is delivered to their team. In both cases, the coupled object replaces the pattern of "headline now, commentary later."
Across the JFK, NBA, and concept test examples on this site, the same three stages produced the same deliverable shape on data that had nothing in common.
Want to apply this to your data?
The case studies show the engine working on public data. The Services page describes how it looks when applied to yours — a short diagnostic on a single study, a full case study built around one of your headlines, or an ongoing methodology partnership across multiple research methods.