# Bruksområder for GenderAPI og ansvarlig måling av resultater > Utforsk praktiske scenarier for databerikelse, og mål resultatene med kontrollgruppe, oppfølging av dekning og vurdering av usikkerhet. Canonical HTML: https://www.genderapi.io/nb/blog/success-stories-companies-thriving-with-genderapi-integration Last reviewed: 2026-09-30 ## Publiseringsinformasjon Først publisert: 2025-07-16T12:00:00.000Z Sist gjennomgått: 2026-09-30T00:00:00.000Z ## Hvordan vurderer du et prosjekt for databerikelse med GenderAPI? Før du starter, fastsetter du formålet og målene du skal bruke, beholder en nøytral kontrollgruppe, lagrer konfidens og ukjente resultater og måler både resultatene og mulige negative konsekvenser. ## Illustrerende scenarier er ikke verifiserte kundecaser Den eldre artikkelen knyttet bestemte tall til anonyme eksempler fra netthandel, helse, mote og finans. Uten opplysninger om kunde, kilde, utvalgsstørrelse, periode eller målemetode kan tallene ikke kontrolleres uavhengig, og de gjengis ikke her som faktiske resultater. De er heller ikke erstattet med andre kunder, logoer, måltall eller omtaler. Scenariene i denne veiledningen er hypoteser som må testes, ikke dokumenterte resultater. Vilkår for å publisere en kundecase Det kreves en kunde som har gitt tillatelse eller er riktig anonymisert, en utgangsverdi, utvalgsstørrelse, periode, metode, målt resultat og tydelig beskrevne begrensninger. ## Fire arbeidsflyter som kan testes forsiktig ### Meldinger i kundereisen i netthandel Berik relevante poster, hold usikre resultater atskilt, og sammenlign en avgrenset personalisering med en nøytral opplevelse. ### Målgruppeanalyse Analyser mønstre på aggregert nivå, og rapporter dekning, ukjente resultater og begrensninger i utvalget. ### Klargjøring av CRM-data Legg til normaliserte felt og støtteverdier, slik at det ansvarlige teamet kan gå gjennom postene før de brukes. ### Kampanjeeksperimenter Ikke behandle estimatet som identitetsopplysning; test om et avgrenset budskap forbedrer et mål som er fastsatt på forhånd. ## Prioriter nyttige og nøytrale opplevelser Et estimat basert på navnet er ikke kjønnsidentiteten personen selv har oppgitt. Sørg for at opplevelsen er nyttig også når resultatet mangler eller er feil. Tilby et nøytralt alternativ, unngå stereotypier, ikke ta viktige beslutninger på grunnlag av et estimert kjønn, og la brukerne rette viktige opplysninger gjennom en egnet kanal hos den som forvalter dataene. Mål arbeidsflyten, ikke antakelser om mennesker. ## Vurder resultatene i fire trinn ### Fastsett mål og beslutningskriterier først Dokumenter hvorfor signalet trengs, hvem som kan bruke det, og hvilke bruksområder som er forbudt. ### Behold en kontrollgruppe Sammenlign den berikede arbeidsflyten med en nøytral opplevelse i stedet for å tilskrive enhver endring ett enkelt felt. ### Mål dekning og usikkerhet Rapporter ukjente, tvetydige og usikre resultater sammen med det valgte forretningsmålet. ### Vurder konsekvensene Se etter negative virkninger, misvisende personalisering og forskjeller mellom regioner eller språk. ## REST API, regneark og automatisering uten kode - [REST API Integrer strukturerte resultater i en app eller en datapipeline. Se dokumentasjonen →](https://www.genderapi.io/nb/api-documentation) - [Google Sheets Test et lite utvalg direkte i et eksisterende regneark. Se veiledningen →](https://www.genderapi.io/nb/blog/how-to-determine-gender-in-google-sheets-using-gender-api-add-on) - [Automatisering uten kode Koble sammen en utløser, et berikelsestrinn og et kontrollert mål. Se veiledningen for Zapier →](https://www.genderapi.io/nb/blog/zapier-gender-api-integration) ## Behold bare de dataene og den tilgangen som trengs Tilordne bare inndataene som trengs for det dokumenterte formålet, begrens tilgangen til API-nøkler og resultater, og bestem når estimerte felt skal gjennomgås eller slettes. Ifølge den publiserte [personvernerklæringen](https://www.genderapi.io/nb/privacy-policy) behandles inndata i vellykkede forespørsler om navn, brukernavn, e-post og andre forespørsler for å returnere resultatet, og de lagres ikke som gjenbrukbare forespørselsposter. Forespørsler som ikke gjelder e-post, og som ikke gir noe kjønnsresultat, kan lagres i opptil 12 måneder for å forbedre GenderAPI; e-postforespørsler er utelukket fra dette forbedringsdatasettet. Opplastede Excel- og CSV-filer planlegges fjernet fra aktive systemer innen fem dager, og slettede data kan bli liggende i tilgangsbegrensede rullerende sikkerhetskopier i opptil 15 dager til. Server-, autentiserings- og sikkerhetslogger følger egne lagringsperioder som er beskrevet i erklæringen. Rettighetene til innsyn, til å protestere og til sletting er beskrevet i [GDPR-personverninformasjonen](https://www.genderapi.io/nb/gdpr-compliance). Tillatelser, kjørelogger og lagringsinnstillinger i CRM-systemet, regnearket og automatiseringstjenesten du kobler til, er atskilt fra innstillingene hos GenderAPI. Ikke gå ut fra at API-versjonen eller resultatfeltene i et tillegg er de samme som i V2. Les data.confidence fra V2 sammen med confidence_kind og source; en KI-verdi og en andel i datasettet er ikke det samme. Rapporter data.result_status: unknown, JSON-verdien null og behandlingsfeil hver for seg. Se [Svarfelt i V2](https://www.genderapi.io/nb/docs/v2/responses), [Metode for vurdering av nøyaktighet](https://www.genderapi.io/nb/accuracy-methodology) og [Datakilder](https://www.genderapi.io/nb/data-provenance). ## Spørsmål om bruksområder og måling av resultater ### Var tallene i den eldre artikkelen verifiserte kundecaser? Nei. Den eldre versjonen oppga verken kunder, kilder, utvalgsstørrelser eller målemetode. Denne versjonen presenterer derfor ikke tallene som dokumentasjon og erstatter dem heller ikke med andre tall. ### Hva må en kundecase inneholde for å kunne publiseres? Kundens tillatelse, en utgangsverdi, utvalgsstørrelse, måleperiode, metode, observert resultat og tydelig beskrevne begrensninger. ### Hvordan måler man en arbeidsflyt for databerikelse? Fastsett målet på forhånd, behold en nøytral kontrollgruppe, dokumenter dekning og usikkerhet, og vurder hele arbeidsflyten. ### Er et estimert kjønn en bekreftet opplysning om en person? Nei. Det er et estimat basert på navnet, ikke kjønnsidentiteten personen selv har oppgitt. Resultatet kan være feil eller upassende, så ikke bruk det som en bekreftet identitet eller som grunnlag for viktige beslutninger. ### Bør ukjente resultater fjernes? Nei. Behold ukjente resultater og resultater med lav konfidens som de er. Andelen deres er en del av datadekningen og datakvaliteten og bør rapporteres sammen med resultatmålene. ### Hvilke data bør en arbeidsflyt for databerikelse lagre? Lagre bare feltene som trengs for det dokumenterte formålet, og fastsett regler for sletting. Ifølge den publiserte personvernerklæringen lagres inndata i vellykkede forespørsler ikke som gjenbrukbare forespørselsposter. Forespørsler som ikke gjelder e-post, og som ikke gir noe kjønnsresultat, kan lagres i opptil 12 måneder for å forbedre GenderAPI. Opplastede Excel- og CSV-filer planlegges fjernet fra aktive systemer innen fem dager og kan bli liggende i tilgangsbegrensede sikkerhetskopier i opptil 15 dager til. Kontroller også loggene og lagringsreglene for hver tilkoblede tjeneste. ### Hvor finner jeg implementeringsveiledninger? Bruk REST API-dokumentasjonen eller veiledningene for Google Sheets, Shopify og automatisering uten kode som det lenkes til på denne siden.