The task and original case
Reconcile two campaign labels using a written normalization rule, while retaining the originals. The input groups are disjoint session counts, so merging their labels is an aggregation choice rather than a person-level deduplication task. The artifact should let a reviewer reverse every mapping.
| Case element | Value or requirement |
|---|---|
| Inputs | Two disjoint session groups: Spring has 100 and spring-space has 50; define a trim/lowercase normalization. |
| Build | A campaign-tag dictionary and a traceable aggregation. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
The raw labels are “Spring” with 100 sessions and “spring ” with 50; the second has a trailing space. Define the exercise's normalization as trimming surrounding whitespace and then lowercasing. Create separate raw_campaign and normalized_campaign columns instead of overwriting the raw strings.
Both labels map to spring. Group the disjoint session counts by that normalized label and sum them. If tags are read from a URL, MDN's URLSearchParams guidance covers parameter parsing; normalization is your additional business rule. Keep a two-row alias dictionary with original label, normalized label and rule version. Do not assume that all case differences are harmless in every tracking system.
Sources[1]
Check the worked result
The normalized spring campaign has 150 sessions. Its raw component counts remain 100 and 50, so a reader can reconstruct the sum. Report that you consolidated labels under the chosen rule, not that you found 150 unique people or corrected a real campaign's performance.
The input explicitly says the groups are disjoint. Without that assumption, simply adding counts could double-count sessions shared by both records. A label-cleaning rule alone cannot establish whether the underlying observations overlap.
Make the failure visible
Add “spring-sale” as another label. Trimming and lowercasing must leave it distinct; a substring-based rule that maps it to spring would overmerge different campaigns. Test an empty label and repeated identical source rows too. Missing labels need a visible category or exception, while repeated source rows need a separate identity policy.
Revise it and ask someone to reproduce it
Ask a peer to predict the mapping for “ SPRING ” and “Spring-Sale.” Add them as revision fixtures, then verify the expected distinction. Keep the dictionary and source counts beside the output. Return to the rule after new tags arrive, and require an explicit mapping change rather than silently editing historical raw values.
- Original labels remain recoverable through an alias dictionary.
- Normalized totals reconcile to disjoint source counts.
- Different campaign names are not merged by a broad substring rule.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Built an independent campaign-tag reconciliation with retained raw labels, a versioned normalization rule and explicit disjoint-count assumptions.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.