Using Multiple Views to Compare Transformations
You're a few steps into a pipeline. Filter by region, group by product, sum the revenue. It's looking good. Then a thought hits: "What if I grouped by customer instead of product?" You don't want to tear apart the pipeline you've built. You want to try the other path without losing the first one.
This is exactly what multi-view tabs solve in ExploreMyData.
What is a view?
A view is an independent analysis branch on the same file. Each view has its own pipeline, filters, sort order, and search state. They all read from the same source data, but everything after that is separate.
Think of it like browser tabs for your analysis. Tab 1 has your product-level summary. Tab 2 has your customer-level summary. Same CSV, two completely different pipelines running simultaneously. Switch between them instantly.
View tabs, along the bottom of the window
Creating a new view
Look at the very bottom of the window. Under the data grid there's a strip with a Grid / Charts toggle on the left, then one tab per view. At the right-hand end of that strip is a + button. Click it and you get a new view on the current file: no pipeline steps, no filters, just the raw data. It's named "View 2", "View 3" and so on.
Double-click a view tab to rename it, which is worth doing the moment you have more than two. "Product summary" beats "View 2" when you come back tomorrow. Once there's more than one view, each tab also gets a small close button to delete it.
The new view starts clean. It doesn't inherit the pipeline from your first view. That's intentional. You want a blank slate for a different approach.
- Select the file tab at the top for the data you want to explore.
- Click the + at the right of the view tab strip at the bottom.
- A new view tab appears. You're now looking at the raw data again.
- Double-click the new tab to give it a name you'll recognise.
- Build your alternative pipeline from scratch.
Example: Comparing two aggregation strategies
Let's say you have a sales dataset with columns for
region,
product,
customer, and
revenue.
View 1, Product summary:
- Filter:
regionisWest - Group & Aggregate: group by
product, aggregate SUM onrevenue
View 2, Customer summary:
- Filter:
regionisWest - Group & Aggregate: group by
customer, aggregate SUM onrevenue
Two steps each, and no sort step in either. Group & Aggregate names its output
revenue_sum automatically. To see
the biggest numbers first, click that column header in the grid, which sorts the view without adding
a step.
Now you can flip between tabs to compare. Which products drive the most revenue? Which customers? The data comes from the same source and the same region filter, so the totals reconcile. Two perspectives, zero pipeline teardown.
View 1: Product summary (West region)
| product | revenue_sum |
|---|---|
| Laptop Pro | 48,200 |
| Cloud Suite | 31,500 |
| Monitor 4K | 19,800 |
| Total | 99,500 |
View 2: Customer summary (West region)
| customer | revenue_sum |
|---|---|
| Acme Corp | 42,300 |
| Globex Ltd | 33,700 |
| Initech Inc | 23,500 |
| Total | 99,500 |
Same filter (region = West), two different grouping dimensions. The West region has exactly three products and three customers here, so each view accounts for every row. 48,200 + 31,500 + 19,800 = 99,500, and 42,300 + 33,700 + 23,500 = 99,500.
That matching total is the check worth doing. If the two views disagree, one of them is dropping rows, and the usual culprit is NULLs in the grouping column or a filter that isn't identical between the views.
When to use multiple views
A/B pipeline comparison. You want to test whether filtering before grouping gives different results than grouping the full dataset and filtering after. Build each approach in its own view. Compare the output. This is especially useful when you're not sure if NULLs or edge cases affect your aggregation.
Different audiences, same data. Your manager wants a high-level summary grouped by quarter. Your analyst colleague wants the row-level detail with calculated columns. Build both as separate views. When someone asks a question, switch to the relevant view instead of reconstructing it.
Raw vs. cleaned data. Keep your first view as the raw import with no transformations, no filters. Use it as a reference to check original values when something looks off in your cleaned view. "Wait, was that NULL in the original data or did my Fill Missing step create it?" One click to check.
Iterative exploration. You're not sure what analysis to run. Start a view, poke around, realize it's a dead end. Instead of undoing everything, leave that view as-is and start a new one. If the dead end turns out to be useful later, it's still there.
Each view is fully independent
This is worth emphasizing. Changing the pipeline in View 2 does not affect View 1 at all. They share the source file, and nothing else. Each view maintains its own:
- Pipeline steps (all operations and transformations)
- Filter state
- Sort order
- Search/find state
- Column visibility and ordering
Deleting a step in one view doesn't touch the other. Adding a column in one view doesn't add it to the other. They're parallel universes that happen to start from the same data.
Practical tips
Don't overdo it. Three or four views on one file is useful. Ten views gets confusing. If you find yourself with that many, you probably need to export intermediate results and work with separate files.
Name your mental models. Keep track of what each view is for. "View 1 is my cleaned data. View 2 is the quarterly summary. View 3 is the outlier investigation." Having a clear purpose for each view keeps your exploration organized.
Use one view as ground truth. Designate your first view as the "don't touch" reference. Raw data, no pipeline. This gives you a quick sanity check when results in other views look unexpected.