In short: BI tools are built for transactional data: one row per event, numeric fields, additive measures. Survey data violates nearly every one of those assumptions. The result is not a slightly imprecise dashboard, it is a wrong one. This piece collects the five breaking points that cost the most time in practice, and sorts out when building it yourself is worth it and when it is not.
The starting situation
A client brings a market research dataset. A .sav file, perhaps a CSV with a codebook in Excel next to it. The request sounds harmless: "Could you build us a dashboard from this? Like the one for the sales figures."
Technically the import takes ten minutes. The problems start afterwards, and they are not obvious, because the dashboard works. It shows numbers. Just the wrong ones.
Breaking point 1: labels are not data
In an SPSS dataset, column q3 contains the value 2. What 2 means is not in the data, it is in the metadata: the variable label ("How satisfied are you overall?") and the value labels (1 = very satisfied … 5 = very dissatisfied).
A standard CSV export throws both away. What remains is a column called q3 holding numbers from 1 to 5. The dashboard then shows an average of 2.4 for "q3", methodologically worthless and uninterpretable for the end user.
The usual workaround is a hand-maintained mapping table. It works right up until the next wave, in which one answer option is added.
Breaking point 2: weights, and what happens without them
This is the most expensive point, because it is invisible.
Samples rarely mirror the population exactly: younger people respond less often, certain regions are over-represented. Market research corrects this with a weighting variable: each case gets a factor, often between 0.3 and 3.0. Only once weighted does the result correspond to the population.
A COUNT or AVERAGE in DAX or SQL ignores that column. The result is not roughly right, it is systematically biased, often by several percentage points, and in a direction nobody notices because there is no reference figure.
It can be rebuilt: weighted means via SUMX, weighted shares via helper measures. The difficulty is not the single measure, it is consistency. Once twenty measures and several filter contexts are in play, the question is no longer whether one place stays unweighted, but which one, and who will notice.
Breaking point 3: multi-response questions do not fit the data model
"Which of these brands do you know?" (multiple answers allowed). In the dataset this lands as a battery of dummy variables: q7_1 through q7_12, each 0 or 1.
To a BI tool these are twelve independent columns. Methodologically they are one question. The difference shows up in the percentage: the base is the number of respondents, not the number of mentions, so the shares correctly add up to more than 100%. Normalising them because the total "looks wrong" produces a number that appears in no report anywhere in the world.
It can be solved cleanly by unpivoting into a long table with a separate base calculation. That is doable, and it is work that recurs for every question battery.
Breaking point 4: significance does not exist in the BI stack
Brand value rises from 42% to 45%. Is that a development or noise?
At n = 500 and those values: noise. Answering it requires a significance test that accounts for sample sizes, weighting and, with multiple comparisons, an alpha correction. No BI tool ships with that. You can compute it in R or Python and feed the result in, but then it is a static appendix rather than part of the interactive analysis: as soon as the user filters, the stored significances no longer hold.
For the end client this is the most dangerous point, because the dashboard looks exactly as though the question had been answered. A bar that is three points higher gets read as an increase, even when it is not one.
Breaking point 5: waves are not a time series
A tracker with eight waves looks like a time series but does not behave like one. Things change between waves: a scale gets reversed, an answer option is added, weighting is switched to new census data, an item is reworded.
Grouping bluntly by wave draws lines across breaks that are methodologically not continuous. The clean approach would be versioning the questionnaire instrument with documented breaks, a concept the BI data model simply does not provide for.
Why this is not a tooling failure
None of this is an argument against Power BI, Tableau or Qlik. These tools are excellent at what they were built for: transactional and event data, additive measures, clean star schemas. Survey data is a different species of data, with metadata that is part of the semantics, non-additive bases and an error calculation that belongs in the presentation.
You can reproduce that species inside the BI stack. The honest question is what it costs: not on the first project, but on the fifth, when every client brings a slightly different questionnaire logic and every wave touches the mappings.
A usable rule of thumb
Building it yourself is worth it when it stays with one dataset, the structure is stable, no weighting is involved and nobody needs significance. That applies to one-off analyses and simple satisfaction surveys.
Building it yourself gets expensive as soon as at least two of these apply: recurring waves, several data suppliers with different formats, weighting, multi-response questions at scale, or end users who are meant to filter for themselves. Maintenance effort then grows not linearly but with the number of combinations.
The point at which it tips in practice is usually not the build; it is the third wave, when somebody asks why the number from back then looks different today.
The middle path: a layer in front
Between "rebuild everything in DAX" and "replace BI" lies a third option that works best in practice: a layer that keeps research data correct (labels, weights, bases, significance, wave logic) and passes the results on to the existing stack.
The BI stack stays where it is and does what it is good at. What it cannot do happens upstream. For consultancies this is the more interesting variant, because the client keeps their investment and the implementation still goes ahead.
Finally, on our own behalf
That layer is exactly what DataLion is: research data with labels, weighting, correct bases, significance and wave logic, queryable by dashboard, by API and by AI, hosted in Germany. We do not replace a BI stack, we deliver into it.
And for the sake of completeness: we do not sell fieldwork, panels or studies. We compete neither with the institutes that collect the data nor with the partners who implement it.
If you run a BI or analytics consultancy and keep running into this species of data: we have a dedicated page for implementation partners.
See it on your own dataset: load an SPSS or Excel export into DataLion and the labels, weights, bases and significance tests are there; then hand the results to your existing stack. For implementation partners or try DataLion for free.