20 ofte stillede interviewspørgsmål til Data Scientist. Data science er et efterspurgt felt, der omsætter produkt-, kunde- og forretningsdata til beslutninger, eksperimenter, modeller og målbare indsigter. Spørgsmålene dækker flere niveauer, og du kan øve dig i at svare mundtligt i vores interviewtræner.
1How do you explain foundational metrics like conversion rates or statistical significance to non-technical business stakeholders without using technical jargon?
When communicating foundational metrics to non-technical stakeholders, the key is to translate abstract formulas and statistical mechanics into intuitive user stories, decision confidence, and business risk. For conversion rate, rather than presenting a bare ratio or abstract percentage, frame it around concrete user counts: 'Out of every 100 people who landed on the checkout page, 5 completed a purchase.' This grounds the metric directly in observable customer behavior. For statistical significance, avoid formal null hypothesis terminology like alpha levels or rejection regions. Instead, explain it as confidence that an observed uplift is real rather than random noise or lucky timing. For instance: 'A statistically significant result means we are 95% confident this improvement reflects a genuine change in user behavior rather than random fluke. Rolling this out gives us high confidence of a positive outcome instead of reacting to random noise.'
## Experiment Results: New Checkout Flow
- Baseline Conversion: 5.0% (5 out of 100 visitors buy)
- Variant Conversion: 5.8% (5.8 out of 100 visitors buy, a +16% relative lift)
- Decision Confidence: 96% confidence (p = 0.04)
- Business Takeaway: The risk that this lift was just random chance is under 4%. Rolling this out is estimated to bring +$45k in monthly revenue.
2Hvad er den konceptuelle forskel mellem inner, left, right og full outer joins, og hvordan ændrer hvert valg den analytiske population og NULL-håndteringen i efterfølgende metrikberegninger?
Inner, left, right og full outer joins definerer, hvilke rækker der bevares, når tabeller kombineres på baggrund af matchende nøgler:
- Inner Join: Bevarer kun rækker, hvor join-nøglen matcher i begge tabeller.
- Left (Outer) Join: Bevarer alle rækker fra venstre tabel og udfylder kolonner fra højre tabel med NULL, når der ikke er et match.
- Right (Outer) Join: Bevarer alle rækker fra højre tabel og udfylder ikke-matchende kolonner fra venstre tabel med NULL.
- Full Outer Join: Bevarer alle rækker fra begge tabeller og indsætter NULL-værdier på begge sider, hvis der mangler et match.
Analytisk population og indvirkning på efterfølgende metrikker:
Valget af join styrer direkte den analytiske kohorte og nævnerne (denominators), der anvendes i metrikberegninger. Et utilsigtet inner join mellem en brugerbase og en aktivitets-/transaktionstabel fjerner inaktive brugere, hvilket reducerer nævneren til udelukkende aktive brugere og kunstigt puster konverterings- eller fastholdelsesrater op. Omvendt bevarer outer joins hele baseline-populationen, men introducerer NULL-værdier for ikke-matchende rækker. Efterfølgende beregninger skal tage højde for disse NULL-værdier: standard SQL-aggregatfunktioner som `SUM()` eller `AVG()` ignorerer NULL-værdier, `COUNT(kolonne)` tæller ikke-NULL-poster, mens `COUNT(*)` tæller alle rækker, og aritmetiske operationer på NULL-værdier uden brug af `COALESCE` returnerer NULL.
-- Inner join silently shrinks denominator to purchasers only
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS inner_conv_rate
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
-- Left join preserves full user base for accurate metric computation
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS true_conv_rate
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;
3In product experimentation, what does randomization achieve that simple before-after comparison usually cannot, and how would you explain the core causal claim an A/B test is designed to support?
In product experimentation, a simple before-after comparison compares metrics across different time periods, which confounds the effect of a feature change with external temporal factors such as seasonality, day-of-week patterns, concurrent marketing campaigns, macro trends, and natural user maturation. Randomization assigns eligible units simultaneously to treatment and control groups, balancing both observed and unobserved confounding variables across groups in expectation. This establishes internal validity. The core causal claim supported by an A/B test relies on counterfactual reasoning: because the control group is subjected to the exact same external conditions over the exact same time window, it serves as an empirical estimate of the counterfactual—what would have happened to the treatment group had they not received the feature. Therefore, any statistically significant difference in outcomes can be causally attributed to the treatment intervention.
# Naive Before-After Comparison:
# Effect_estimate = Metric_t1 (Holiday Launch) - Metric_t0 (Pre-Holiday Baseline)
# Problem: Lift is confounded by holiday shopping surge and marketing spend.
# Randomized A/B Test:
# Effect_estimate = E[Metric_Holiday | Treatment] - E[Metric_Holiday | Control]
# Solution: Both arms experience the exact same external shocks simultaneously.
4Hvad er det primære formål med EDA (Exploratory Data Analysis, eksplorativ dataanalyse) forud for formel modellering eller eksperimentering, og hvordan adskiller EDA sig fra bekræftende analyse?
Exploratory Data Analysis (EDA) er en åben proces, der har til formål at forstå den underliggende struktur i et datasæt, afdække mønstre, identificere anomalier eller datakvalitetsproblemer, vurdere fordelingsantagelser og generere hypoteser, før man bygger formelle statistiske modeller eller udfører eksperimenter. Den væsentligste forskel mellem EDA og bekræftende analyse ligger i deres formål og metode: EDA er hypotesegenererende, fleksibel og eksplorativ — den anvender deskriptive opsummeringer, korrelationer og visualiseringer til at undersøge, hvad data antyder, uden strenge forhåndsforpligtelser. Omvendt er bekræftende analyse (såsom hypotesetestning eller evaluering af A/B-tests) hypotesetestende, struktureret og inferentiel — designet til stringent at teste foruddefinerede, falsificerbare hypoteser med kontrol over statistiske fejlfrekvenser (f.eks. type I-fejl). Hvis man behandler fund opdaget under EDA som bekræftede konklusioner på det samme datasæt, kan det føre til data dredging (p-hacking) og overfitting.
import numpy as np
import pandas as pd
# 1. EDA Phase: Open-ended discovery and hypothesis generation
df = pd.DataFrame({'engagement_score': np.random.normal(50, 10, 1000)})
summary = df['engagement_score'].describe()
# 2. Confirmatory Phase: Testing pre-registered hypothesis on fresh test/experiment data
# (e.g., two-sample t-test with fixed significance level alpha = 0.05)
5Hvad er target leakage inden for superviseret læring, og hvordan adskiller det sig fra en legitim, stærk korrelation mellem en feature og målet (label)?
Target leakage opstår, når en feature i modeltræningen indeholder information om målvariablen (target label), som ikke ville være legitimt tilgængelig på inferenstidspunktet, når modellen foretager forudsigelser i praksis. Dette sker ofte, når en feature indsamles kronologisk efter den pågældende hændelse, eller når den er en direkte konsekvens eller et efterfølgende spor af målet (for eksempel ved at bruge tidsstemplet for en opsigelse af en konto eller et refunderings-id til at forudsige kundeafgang). I modsætning hertil afspejler en legitim stærk korrelation et reelt, eksisterende prædiktivt eller kausalt forhold, som er fuldt ud kendt og tilgængeligt forud for forudsigelsestidspunktet (såsom en kundes loginfrekvens over de seneste 30 dage). Selvom begge dele vil udvise høj feature importance eller gode evalueringsmetrikker, vil en model med target leakage opnå urealistisk høje offline valideringsresultater, men fejle i produktion, fordi den lækkede feature ikke kan kendes på inferenstidspunktet.
# Scenario: Predicting whether a user will cancel their subscription (is_churned)
# LEAKY FEATURE:
# 'cancellation_survey_submitted' -> Occurs after the decision to churn has executed.
# LEGITIMATE FEATURE:
# 'login_count_last_30_days' -> Observed strictly before the prediction cut-off date.
6Hvad er formålet med at opdele data i trænings-, validerings- og testsæt, og hvordan bør hver opdeling guide iterativ modeludvikling?
Opdeling af data i trænings-, validerings- og testsæt adskiller modelfitting, hyperparameterjustering og endelig evaluering for at sikre generalisering til usete data. - Træningssæt (Training Set): Bruges til at tilpasse modellens interne parametre (f.eks. vægte og biases i neurale netværk, splittærskler i træer). - Valideringssæt (Validation Set): Bruges under den iterative udvikling til modeludvælgelse, hyperparameterjustering, variabeludvælgelse (feature selection) og detektering af overtilpasning (overfitting). Det guider beslutninger om, hvilken modelarkitektur eller konfiguration der præsterer bedst, uden at røre de endelige evalueringsdata. - Testsæt (Test Set): Fungerer som en strengt tilbageholdt repræsentant for usete produktionsdata. Det evalueres kun én enkelt gang i slutningen af projektet for at give et uvildigt estimat af generaliseringsfejlen. Genjustering af modeller baseret på testsættets resultater ødelægger dets objektivitet og introducerer optimistisk bias.
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_classification
X, y = make_classification(n_samples=1000, n_features=10, random_state=42)
# Step 1: Split off final test set (20%)
X_dev, X_test, y_dev, y_test = train_test_split(
X, y, test_size=0.20, random_state=42, stratify=y
)
# Step 2: Split remaining development data into train (75% of dev = 60% total) and validation (25% of dev = 20% total)
X_train, X_val, y_train, y_val = train_test_split(
X_dev, y_dev, test_size=0.25, random_state=42, stratify=y_dev
)
print(f"Train size: {len(X_train)}, Val size: {len(X_val)}, Test size: {len(X_test)}")
7Hvad er forskellen mellem overvåget læring (supervised learning) og ikke-overvåget læring (unsupervised learning), og hvordan afgør tilgængeligheden af labels og forretningsmæssige mål, hvilket paradigme man skal vælge?
Algoritmer til overvåget læring lærer en matematisk afbildning fra inputattributter (X) til kendte mållabels (y) ved hjælp af annoterede historiske data for at forudsige udfald på nye observationer. Ikke-overvåget læring analyserer datasæt, der udelukkende indeholder inputattributter (X), for at opdage iboende mønstre, naturlige grupperinger (klyngedannelse/clustering) eller reducerede repræsentationer uden foruddefinerede mållabels. Valget mellem paradigmerne afhænger af tilgængeligheden af labels og de forretningsmæssige mål: Hvis der findes 'ground truth'-labels, eller det er realistisk at indsamle dem, og forretningsmålet er målrettet prædiktion (f.eks. afsløring af svindel, forudsigelse af kundeafgang eller prisprognoser), er overvåget læring det rette valg. Hvis 'ground truth'-labels ikke findes, er uoverkommeligt dyre at fremskaffe, eller målet er åben udforskning (f.eks. kundesegmentering eller anomalidetektion uden kendte labels), vælges ikke-overvåget læring.
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.cluster import KMeans
X = np.array([[10, 2], [12, 3], [1, 8], [2, 9]])
y = np.array([0, 0, 1, 1])
# Supervised: Learns mapping X -> y
clf = LogisticRegression().fit(X, y)
# Unsupervised: Discovers clusters directly from X
kmeans = KMeans(n_clusters=2, random_state=42, n_init=10).fit(X)
8Hvad er en North Star Metric (NSM), og hvordan skelner man en effektiv North Star fra en forfængelighedsmetrik (vanity metric), når man evaluerer et produkts tilstand?
En North Star Metric (NSM) er den primære metrik, der bedst indfanger den kerneværdi, et produkt leverer til sine kunder, samtidig med at den driver bæredygtige forretningsresultater (f.eks. 'Nights Booked' for Airbnb eller 'Weekly Active Streaming Hours' for en musikplatform). Den samler produktteams om langsigtet kundeværdi frem for overfladisk vækst. For at skelne en effektiv North Star fra en vanity metric vurderes følgende: 1. Værditilpasning (Value Alignment): En effektiv North Star afspejler reel brugerværdi og aktivt engagement, hvorimod en vanity metric måler overfladisk volumen (såsom samlet antal registrerede brugere, akkumulerede app-downloads eller rå sidevisninger), som kan vokse, selvom brugerne falder fra med det samme. 2. Handlekraft og korrelation (Actionability and Correlation): En effektiv North Star korrelerer med brugerfastholdelse (retention), produktsundhed og indtjening, og den reagerer direkte på forbedringer i produktkvaliteten. Vanity metrics kan sjældent knyttes til reel fastholdelse eller forretningsmæssig sundhed og er modtagelige for overfladisk oppustning.
Platform: Vacation Rental App
Vanity Metric: Cumulative app downloads (increases continuously even if 95% of users uninstall immediately).
North Star Metric: Nights booked per active user (reflects actual value exchange between guests and hosts).
9Hvad er den praktiske forskel mellem datadrift og konceptdrift, og hvorfor er en korrekt kategorisering af dem afgørende for vedligeholdelse af modeller efter lancering?
Datadrift (ofte kaldet covariate shift) opstår, når den statistiske fordeling af input-features P(X) ændrer sig over tid, mens den betingede sammenhæng mellem input og målvariablen P(Y|X) forbliver uændret. I modsætning hertil opstår konceptdrift, når den underliggende sammenhæng mellem input og målvariablen P(Y|X) ændrer sig, hvilket betyder, at identiske feature-værdier nu svarer til anden måladfærd eller andre udfald. Korrekt kategorisering af dem er afgørende for vedligeholdelse efter lancering, fordi deres udbedringsmetoder er fundamentalt forskellige. Ved datadrift forbliver historiske mønstre gyldige; vedligeholdelsen fokuserer på at udvide træningsdækningen til nye feature-områder, opdatere præprocessering eller anvende genvægtning af stikprøver. Ved konceptdrift afspejler historiske labels ikke længere den aktuelle sandhed (ground truth); vedligeholdelsen kræver indsamling af nye annoterede data, udfasning af forældede historiske eksempler og gentræning eller redesign af modellen.
# Data Drift (Covariate Shift):
# User demographics or devices change (P(X) shifts),
# but genuine vs fraudulent transaction patterns remain identical (P(Y|X) unchanged).
# Concept Drift:
# Fraudsters adapt tactics to mimic normal shopping patterns;
# identical feature inputs now have a higher probability of fraud (P(Y|X) shifts).
10Hvad er forskellen mellem en populationsparameter og en stikprøvestatistik, og hvordan påvirker stikprøvevariabilitet fortolkningen af metrikker?
En populationsparameter er en fast, typisk ukendt numerisk egenskab ved en hel population (såsom den sande populationsmiddelværdi μ eller proportion p). En stikprøvestatistik er en numerisk opsummering beregnet ud fra observerede stikprøvedata (såsom stikprøvegennemsnittet x̄ eller stikprøveproportionen p̂), der bruges til at estimere den ukendte parameter. Stikprøvevariabilitet refererer til den naturlige variation i stikprøvestatistikker på tværs af forskellige tilfældige stikprøver udtaget fra den samme population. På grund af stikprøvevariabilitet er enhver enkelt stikprøvemetrik underlagt tilfældig usikkerhed og matcher sjældent den sande populationsparameter præcist. Ved fortolkning af metrikker fører manglende hensyntagen til denne variabilitet til, at man forveksler støj med reelle ændringer. Analytikere skal kvantificere estimeringsusikkerhed ved hjælp af standardfejl, konfidensintervaller eller hypotesetest, før de konkluderer, at en observeret forskel er reel.
import numpy as np
# True population parameter (mean = 50, standard deviation = 10)
pop_mean = 50.0
pop_std = 10.0
# Draw multiple independent samples of size n=30
np.random.seed(42)
sample_means = [np.mean(np.random.normal(pop_mean, pop_std, size=30)) for _ in range(5)]
for i, sm in enumerate(sample_means, 1):
print(f"Sample {i} Mean (Statistic): {sm:.2f} | Error: {sm - pop_mean:+.2f}")
11En interessent stiller et tvetydigt spørgsmål såsom »Virker funktion Y?« Hvordan omformulerer du den anmodning til en målbar analyseramme, der er klar til beslutningstagning?
Når en interessent spørger »Virker funktion Y?«, starter jeg med at dekonstruere spørgsmålet til dets underliggende hensigt: Hvilket problem blev funktion Y bygget til at løse, hvem er den beregnet til, og hvilken beslutning skal træffes på baggrund af svaret (f.eks. iterere, skalere op eller udfase)? Derefter opstiller jeg en målemodel i flere niveauer bestående af: 1. Udbredelse og engagement (adoption and engagement): Opdager målbrugerne funktionen og bruger den som forventet? 2. Direkte værdi / opgavegennemførelse (task success): Gennemfører brugerne det primære workflow, som funktionen understøtter? 3. Afledt forretningsmæssig indvirkning (downstream business impact): Korrelerer eller driver funktionsudbredelsen centrale overordnede nøgletal (f.eks. fastholdelse, konvertering, omsætning)? 4. Sikkerhedsrammer (guardrails): Har funktionen skabt utilsigtede negative bivirkninger (f.eks. øget svartid, flere supportsager, kannibalisering)? Til sidst forhåndsdefinerer jeg beslutningstærskler og evalueringskriterier sammen med interessenten, før analysen udføres, for at sikre enighed om, hvad der udgør en succes, og for at undgå, at succeskriterierne flyttes retrospektivt.
Feature: Quick Checkout Button
1. Primary Decision: Keep & expand vs. Redesign vs. Deprecate
2. Evaluation Metrics:
- Adoption: % of checkout sessions clicking the quick button (Target: >= 15%)
- Funnel Completion: Checkout completion rate given button click (Target: >= 75%)
- Business Metric: Overall cart conversion lift (Target: +1.5% in A/B test)
- Guardrail: Support tickets for accidental purchases (Threshold: < 0.2% increase)
3. Pre-agreed Action Plan:
- If Target Met: Roll out to 100% and promote to mobile app.
- If Adoption Low but Completion High: Retain, optimize UI discovery.
- If Guardrail Exceeded: Halt rollout, add confirmation step.
12Når du forbereder og renser et datasæt (data wrangling) med en betydelig mængde manglende værdier, hvordan vælger du så mellem complete-case-analyse, simpel imputation, indikatorflag for manglende data og modelbaseret imputation?
Valget af strategi for manglende data afhænger primært af mekanismen bag de manglende værdier (MCAR, MAR, MNAR), andelen af manglende data, slutanvendelsen (statistisk inferens vs. prædiktiv modellering) og risikoen for bias: 1. **Complete-Case-analyse (fjernelse af rækker):** Kun hensigtsmæssig, når data er Missing Completely at Random (MCAR), og den manglende andel er lille (f.eks. <5 %). Hvis data er Missing at Random (MAR) eller Missing Not at Random (MNAR), introducerer fjernelse af rækker alvorlig selektionsbias og kasserer værdifuld stikprøvestyrke. 2. **Simpel imputation (middelværdi/median/typital):** Hurtig og praktisk til baseline-modeller i prædiktiv modellering, men risikabel til statistisk analyse, fordi det kunstigt reducerer egenskabernes varians, oppuster teststatistikker og forvrider kovariansstrukturer. 3. **Indikatorflag for manglende data (imputation + binært flag):** Ideel til prædiktiv modellering (især træbaserede algoritmer) og tilfælde, hvor det, at data mangler, er informativt (MNAR, såsom udeladte valgfrie felter). Det bevarer signalet om manglende data uden at forvride gyldige numeriske fordelinger. 4. **Modelbaseret imputation (KNN, MICE, Iterative Imputer):** Foretrækkes, når data er MAR, korrelationerne mellem variable er stærke, og det er afgørende at bevare multivariate relationer eller standardfejl for parametre (f.eks. ved regressionsinferens). Ulemperne er beregningsmæssig kompleksitet, ekstra implementeringsarbejde i produktions-pipelines og potentiel datalækage (data leakage), hvis modellen ikke tilpasses udelukkende på træningsfolds.
from sklearn.impute import SimpleImputer
import pandas as pd
df = pd.DataFrame({'income': [50000, None, 75000, None, 120000]})
# Impute median while tracking missingness pattern
imputer = SimpleImputer(strategy='median', add_indicator=True)
imputed_data = imputer.fit_transform(df)
# Returns: [income_imputed, income_is_missing]
13Et produktteam sammenligner brugere, der aktivt tilmeldte sig en ny funktion, med brugere, der ikke gjorde, og finder en 20 % højere fastholdelsesrate. Hvordan vil du diagnosticere selektionsbias og confounding, og hvordan vil du redesigne evalueringen?
At sammenligne brugere, der aktivt har tilmeldt sig (opt-in), med brugere, der ikke har, lider under selvselektionsbias og confounding (forvekslingseffekter). Brugere, der aktivt vælger at tage en ny funktion i brug, har typisk et højere udgangspunkt for hensigt, engagement eller teknisk kompetence. Som følge heraf blander den observerede forskel i fastholdelse på 20 % den sande kausale effekt af funktionen sammen med brugernes forudgående motivation. Diagnosticering af bias: 1. Sammenligning af kovariater før intervention: Sammenlign baseline-attributter mellem tilmeldte og ikke-tilmeldte kohorter forud for introduktionen af funktionen (f.eks. historisk aktivitet, tidligere fastholdelse, anciennitet, transaktionsfrekvens, enhedssammensætning). Signifikante forskelle bekræfter tilstedeværelsen af confounding. 2. Tjek af præ-tendenser / placebo-tjek: Evaluer, om tilmeldte brugere allerede udviste højere fastholdelse eller engagement i perioderne før funktionens lancering. Redesign af evalueringen: - Randomiseret eksperiment (guldstandarden): Implementer et Randomized Encouragement Design (eller trinvis randomiseret udrulning). Alle kvalificerede brugere randomiseres til enten Treatment (tilbydes funktionen / opfordring) eller Kontrol (tilbydes ikke). Analyser ved hjælp af ITT (Intention-to-Treat) for den overordnede tilbudseffekt, og instrumentelle variable / 2SLS (Two-Stage Least Squares) med tildelingen som instrument til at estimere LATE (Local Average Treatment Effect) på aktive brugere. - Kvasieksperimentelle metoder (hvis randomisering er umulig): Anvend PSM (Propensity Score Matching), DiD (Difference-in-Differences) eller syntetisk kontrol for at justere for observerbare baseline-confoundere og parallelle forudgående tendenser.
import statsmodels.formula.api as smf
import pandas as pd
# df columns: ['user_id', 'post_period', 'opted_in', 'retained']
# Interaction term captures causal lift above baseline group differences
model = smf.ols('retained ~ opted_in + post_period + opted_in:post_period', data=df).fit()
print(model.summary().tables[1])
14Hvordan ville du designe kohorteopdelinger til en undersøgelse af aktivering eller fastholdelse for at sikre, at sammenligninger ikke forstyrres af mix-forskydninger (mix shifts) eller umodenhedstrunkering (maturity truncation)?
Sådan designes kohorteopdelinger, der undgår mix-forskydninger og umodenhedstrunkering: 1. **Standardiser anciennitetsvinduer (Tenure Windows)**: Juster kohorter efter relativ anciennitet (f.eks. dag 0, dag 7, dag 30 efter tilmelding/aktivering) frem for kalenderdatoer for at sikre retfærdige livscyklussammenligninger. 2. **Håndter umodenhedstrunkering (Right-Censoring)**: Evaluer udelukkende kohorter, der er fuldt modnet gennem hele observationsvinduet. Udelad eller marker eksplicit nyere kohorter, der endnu ikke har haft den fulde varighed til at nå milepælen. 3. **Begræns mix-forskydninger**: Segmenter kohorter på tværs af væsentlige konfunderende dimensioner (såsom akkvisitionskanal, platform, land eller brugerhensigt). Hvis der rapporteres et samlet aggregeret tal, bør der anvendes standardiserings-/post-stratifikationsvægtning, så forskydninger i fordelingen af brugeranskaffelseskilder ikke forvrider den overordnede fastholdelsestendens.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', signup_time) AS cohort_week,
signup_time,
acquisition_channel
FROM users
-- Exclude cohorts that have not reached 7 full days of maturity
WHERE signup_time <= CURRENT_DATE - INTERVAL '7 days'
),
user_activity AS (
SELECT DISTINCT
c.user_id,
c.cohort_week,
c.acquisition_channel,
1 AS retained_d7
FROM user_cohorts c
JOIN events e ON c.user_id = e.user_id
WHERE e.event_time >= c.signup_time + INTERVAL '7 days'
AND e.event_time < c.signup_time + INTERVAL '8 days'
)
SELECT
c.cohort_week,
c.acquisition_channel,
COUNT(c.user_id) AS cohort_size,
COUNT(a.user_id) AS d7_active_users,
ROUND(100.0 * COUNT(a.user_id) / COUNT(c.user_id), 2) AS d7_retention_pct
FROM user_cohorts c
LEFT JOIN user_activity a ON c.user_id = a.user_id
GROUP BY 1, 2
ORDER BY 1 DESC, 2;
15Under evalueringen opnår din model en usædvanlig høj metrik som f.eks. en AUC (Area Under the Curve) på 0,99, men ydeevnen falder drastisk i shadow testing. Hvordan isolerer og verificerer du systematisk target leakage?
Når en model opnår en urealistisk høj offline-metrik (f.eks. en AUC på 0,99), som falder drastisk i live shadow testing, er target leakage (mållækage) den primære mistænkte. En systematisk arbejdsgang til isolering og verificering omfatter: 1. Feature-betydning og attribuering: Beregn SHAP-værdier, gain importances eller permutationsbetydning for at identificere kandidat-features med dominerende prædiktiv kraft. 2. Enkelt-feature-modeller og ablationsstudier: Træn simple modeller med én feature (f.eks. overfladiske beslutningstræer eller logistisk regression) på individuelle mistænkelige features. Hvis en enkelt feature opnår nær-perfekt klassificering, lækker den sandsynligvis målet (target). Fjern (ablate) sekventielt mistænkte features, og mål faldet i offline-ydeevne. 3. Revision af tidsmæssig afstamning og tidsstempler: Kontrollér de nøjagtige oprettelses-/opdateringstidsstempler for kandidat-features i forhold til skæringstidsstemplet for prædiktionen. Verificer, om feature-værdien kun kunne være kendt, efter at målhændelsen fandt sted (f.eks. `cancellation_reason` eller `refund_status`, der først udfyldes ved churn/tilbageførsel). 4. Dataproveniens (data lineage) og teknisk verificering: Gennemgå den opstrøms datapipeline og tabelmutationslogik (f.eks. foranderlige tabeller opdateret direkte i forhold til append-only uforanderlige logs) for at verificere, hvornår felterne udfyldes.
from sklearn.metrics import roc_auc_score
from sklearn.tree import DecisionTreeClassifier
leakage_candidates = {}
for col in X_train.columns:
clf = DecisionTreeClassifier(max_depth=2)
clf.fit(X_train[[col]], y_train)
preds = clf.predict_proba(X_test[[col]])[:, 1]
auc = roc_auc_score(y_test, preds)
if auc > 0.85:
leakage_candidates[col] = auc
print("Candidate Leaky Features:", leakage_candidates)
16Hvordan vælger du mellem standard K-Fold, Stratified K-Fold og Group K-Fold krydsvalidering, når du evaluerer strukturerede data fra den virkelige verden?
Valget mellem standard K-Fold, Stratified K-Fold og Group K-Fold afhænger af målvariablens fordeling og rækkernes uafhængighed:
1. **Standard K-Fold**: Deler data tilfældigt op i K lige store folds. Metoden antager, at observationerne er uafhængige og identisk fordelte (IID - Independent and Identically Distributed), og den bruges typisk til kontinuerlige regressionsmål eller velbalancerede datasæt.
2. **Stratified K-Fold**: Sikrer, at hver fold bevarer den samme procentdel af målklassens labels som det samlede datasæt. Dette er afgørende for klassifikationsopgaver, især ved ubalance mellem klasser, for at undgå at folds indeholder for få eller slet ingen eksempler fra minoritetsklassen.
3. **Group K-Fold**: Sikrer, at særskilte grupper/entiteter (f.eks. `user_id`, `patient_id`, `device_id`) ikke optræder i både trænings- og valideringsfolds samtidigt. Når flere observationer stammer fra den samme entitet, medfører standardopdeling alvorlig datalækage (data leakage), fordi modellen lærer entitetsspecifikke træk udenad i stedet for at lære generaliserbare mønstre. Group K-Fold evaluerer, hvor godt modellen generaliserer til helt nye entiteter.
17Hvordan vælger du mellem logistisk regression, Gradient Boosted Decision Trees (GBDT) og ikke-lineære neurale arkitekturer til tabellarisk klassifikation under begrænsninger på latenstid og dataafvigelse (drift)?
Valget mellem logistisk regression (LR, Logistic Regression), Gradient Boosted Decision Trees (GBDT) og neurale netværk (NN) til tabellarisk klassifikation indebærer en afvejning af prædiktionskraft, krav til inferenslatenstid, forklarbarhed og modstandsdygtighed over for datadrift. 1. Logistisk regression udmærker sig i miljøer med ultralav latenstid (<1-5 ms p99) og stærkt begrænsede beregningsbudgetter. Da beregningen af scoren blot er et simpelt prikprodukt, er den ekstremt hurtig og robust. Ved kovariatdrift eller feature-værdier uden for træningsfordelingen (out-of-distribution) ekstrapolerer lineære modeller monotont, hvilket kan være forudsigeligt eller farligt afhængigt af de regulariserede hældninger, men de producerer sjældent uregelmæssig trinvis adfærd. LR kræver dog omfattende manuel feature engineering (interaktioner, ikke-lineær binning) for at matche ikke-lineære arkitekturer. 2. GBDT'er (f.eks. XGBoost, LightGBM, CatBoost) er standardreferencen i industrien til tabellariske data. De fanger komplekse, ikke-lineære interaktioner direkte og håndterer blandede datatyper samt manglende værdier uden problemer. Hvad angår latenstid, opfylder optimerede GBDT'er (eller modeller kompileret via Treelite/ONNX) nemt SLA'er på under 10 ms. Ved drift kan GBDT'er ikke ekstrapolere ud over de observerede grænser fra træningen (forudsigelser fastlåses ved yderbladene), hvilket fungerer som en indbygget sikkerhedsmekanisme mod vild ekstrapolering, men risikerer forældede trinvise forudsigelser, hvis feature-fordelingerne forskydes væsentligt. 3. Neurale arkitekturer (f.eks. FT-Transformer, TabNet, MLP) foretrækkes, når tabellariske data er multimodale (kombineret med tekst, embeddings eller billeder) eller i kontinuerlige online-læringsscenarier. Imidlertid har rene tabellariske neurale netværk typisk højere inferenslatenstider (da de kræver matrixmultiplikationer over flere lag eller GPU-acceleration), er mere beregningstunge at træne og er yderst følsomme over for uskallerede input og kovariatdrift. I praksis: Start med GBDT som en stærk baseline for ydeevne; hvis der kræves streng mikrosekund-latenstid eller enkel forklarbarhed, anvendes LR; brug primært neurale netværk til multimodale arkitekturer eller overførsel af embeddings.
decision_matrix = {
"Logistic Regression": {"Latency": "<1ms (Ultra-low)", "Drift Behavior": "Linear extrapolation", "Tabular Baseline": "Moderate (needs feature engineering)"},
"GBDT (XGB/LightGBM)": {"Latency": "1-15ms (Fast)", "Drift Behavior": "Leaf clamping (no extrapolation)", "Tabular Baseline": "State of the Art"},
"Tabular Neural Net": {"Latency": "10-50ms+ (Higher)", "Drift Behavior": "Nonlinear extrapolation", "Tabular Baseline": "Competitive / High tuning cost"}
}
for model, traits in decision_matrix.items():
print(f"{model}: Latency={traits['Latency']}, Tabular Perf={traits['Tabular Baseline']}")
18Ledelsen skal beslutte, om der skal gennemføres en større national udrulning af en funktion under tvetydige forhold, herunder blandede regionale eksperimentresultater og faste lanceringsvinduer. Hvordan designer du rammen for den strategiske anbefaling?
For at opbygge en strategisk anbefaling under tvetydige regionale eksperimentresultater og faste lanceringsvinduer bør beslutningen adskilles fra et binært ja/nej-valg. Først nedbrydes de aggregerede resultater til heterogene behandlingseffekter på tværs af markedssegmenter, brugerkohorter og driftsmiljøer for at isolere, hvor funktionen har succes, går i stå eller gør skade. For det andet designes en risikoafdækket, trinvis udrulningsstrategi (såsom regional fasedeling eller canary-deployeringer), der prioriterer segmenter med høj sikkerhed og samtidig isolerer ekstreme negative risici. For det tredje etableres eksplicitte, forud fastlagte grænseværdier (guardrail metrics) og automatiske afbrydere/tilbagerulningstærskler for at begrænse 'worst-case'-nedsiderisikoen. Til sidst struktureres ledelseskommunikationen omkring forventet værdi, asymmetrisk nedsiderisiko versus de kommercielle omkostninger ved at misse det faste vindue, samt operationelle drejebøger for ændringer undervejs.
| Rollout Tier | Target Markets | Launch Exposure | Guardrail Circuit-Breaker | Expected Value / Risk Profile |
|---|---|---|---|---|
| Tier 1: Immediate Launch | Cohorts with stat-sig positive lift (e.g., Regions A, C) | 100% | Rollback if 48h conversion drops > 1.5% | High upside; verified market fit |
| Tier 2: Phased Staging | High-variance / neutral cohorts (e.g., Region B) | 10% -> 25% -> 50% over 14 days | Hold expansion if CSAT drops > 2.0% | Moderate upside; bounded downside |
| Tier 3: Hold & Re-test | Stat-sig negative cohorts (e.g., Region D) | 0% (Holdout / internal testing) | Launch blocked until root-cause resolution | Eliminates primary churn risk |
19Hvordan ville du opbygge arkitekturen for et centraliseret semantisk lag på tværs af et enterprise data warehouse for at sikre ensartede definitioner af forretningsmæssige metrikker på tværs af forskellige analyseteams?
Arkitekturering af et centraliseret semantisk lag på tværs af et enterprise data warehouse kræver etablering af et deklarativt, kodebaseret metrikdefinitionslag (såsom MetricFlow/dbt Semantic Layer, Cube eller LookML), der afkobler forretningslogik fra fysisk lagring og downstream-forbrugsværktøjer (BI-platforme (Business Intelligence), Python/R-notebooks, API'er (Application Programming Interface)). Kerneinfrastrukturen definerer entiteter, dimensioner, målinger og afledte metrikker i versionsstyrede repositories (Git) for at levere en single source of truth og håndhæve ensartethed i metrikker på tværs af teams. For at understøtte multi-tenancy og styring på tværs af separate forretningsenheder bør der anvendes en fødereret governance-model: centrale virksomheds-KPI'er (Key Performance Indicators) (f.eks. ARR, aktive brugere) ejes af et centralt datagovernance-team, mens domænespecifikke metrikker administreres af decentraliserede domæneteams via isolerede semantiske modeller med CI/CD-validering (Continuous Integration/Continuous Deployment). Det semantiske lag udstiller derefter standardiserede forespørgselsgrænseflader (SQL, GraphQL, REST) med samlet rollebaseret adgangskontrol og caching/præ-aggregering for at opretholde ydeevne og konsistens.
semantic_model:
name: orders
node_relation:
alias: fct_orders
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: country
type: categorical
measures:
- name: total_revenue
expr: revenue_usd
agg: sum
- name: distinct_buyers
expr: user_id
agg: count_distinct
metrics:
- name: average_order_value
description: "Governed metric for AOV across all BI tools"
type: ratio
type_params:
numerator: total_revenue
denominator: distinct_buyers
20Hvordan ville du på en to-sidet markedsplads (såsom samkørsel eller e-handel) designe et eksperiment til at evaluere en ændring i en matchningsalgoritme, samtidig med at der tages højde for kannibalisering mellem udbud og efterspørgsel samt rumlig-tidsmæssig interferens?
På to-sidede markedspladser krænker evaluering af matchningsalgoritmer ved hjælp af standard A/B-test på brugerniveau antagelsen om stabile behandlingsenhedsværdier (SUTVA, Stable Unit Treatment Value Assumption). Når behandlingsenheder forbruger knappe delte ressourcer (såsom chauffører eller varelager), kannibaliserer de kontrolenheder, hvilket fører til kunstig forringelse af kontrolgruppen og oppustede behandlingseffekter på grund af forskydninger i markedsligevægten. For at håndtere rumlig og tidsmæssig interferens anvender vi to primære eksperimentelle arkitekturer: klyngebaseret randomisering og switchback-eksperimenter. Ved rumlig klyngerandomisering randomiseres geografiske markeder eller isolerede underregioner (f.eks. afgrænsede metropolområder eller graf-partitionerede sekskantede rumlige celler) til behandling eller kontrol. Dette isolerer direkte interaktioner mellem udbud og efterspørgsel, om end det kræver metoder som syntetiske kontroller eller difference-in-differences til at håndtere heterogenitet på tværs af markeder. I switchback-eksperimenter (tidsopdelte eksperimenter) skifter hele isolerede markeder mellem behandlings- og kontrolalgoritmer over diskrete tidsvinduer (f.eks. skift hver 1-2 time). Switchbacks opretholder en fælles markedsbalance mellem udbud og efterspørgsel inden for hvert vindue, men introducerer tidsmæssig overførselsskævhed (carryover bias). For at afbøde overførselsskævhed i switchbacks indfører vi overgangsbuffer- eller udvaskningsperioder (washout periods) mellem vinduerne (hvor ordrer kasseres under tilstandsovergange) og vælger vindueslængder, der er lange nok til at absorbere omplacering af udbud, men korte nok til at bevare statistisk styrke. Analysen skal tage højde for serielt korrelerede tidsserierfejl ved at klynge standardfejl på tidsblok-/markedsniveau eller ved at anvende Generalized Estimating Equations (GEE) / Newey-West-variansestimatorer.
import pandas as pd
import numpy as np
def generate_switchback_schedule(n_days=14, window_minutes=60, washout_minutes=15):
total_windows = int((n_days * 24 * 60) / window_minutes)
np.random.seed(42)
treatments = np.random.binomial(1, 0.5, size=total_windows)
schedule = []
for i, trt in enumerate(treatments):
start_min = i * window_minutes
eval_start_min = start_min + washout_minutes
end_min = (i + 1) * window_minutes
schedule.append({
'window_id': i,
'treatment': trt,
'start_min': start_min,
'eval_start_min': eval_start_min,
'end_min': end_min
})
return pd.DataFrame(schedule)