Veiledning for ansvarlig bruk av markedsdata

Les som Markdown

Vurder navnebaserte kjønnsdata i markedsføring

Behandle estimatet som et usikkert signal, tilby et nøytralt alternativ, og bruk kontrollerte tester for å avgjøre om det gir relevant verdi.

Mål før du skalerer

Start med beslutningen, ikke egenskapen

Fastsett mål og suksesskriterier først. Minimer deretter inndataene, bevar usikkerheten, og sammenlign den berikede opplevelsen med et nyttig nøytralt utgangspunkt.

  • Legitimt formål
  • Nøytralt alternativ
  • Kontrollert test
  • Konsekvensvurdering
Se hvordan GenderAPI integreres
Instrumentpanel for måling av effekten av berikede kundedata
Planlegg og mål en ansvarlig arbeidsflyt for databerikelse.

Forstå signalet

Et estimat er ikke en bekreftet opplysning om en person

Navnebasert analyse estimerer et sannsynlig resultat ut fra mønstre i tilgjengelige data, men sier ikke noe om kjønnsidentiteten personen selv har oppgitt. Samme navn brukes i mange regioner og av personer med ulike kjønnsidentiteter, så resultatet kan være ukjent eller feil. Pålitelig landkontekst kan hjelpe, men gjør ikke estimatet til et faktum om en enkeltperson. Behold ukjente resultater som de er, i stedet for å tvinge dem inn i en gruppe.

Grensesnitt som illustrerer signaler i kundedata
Gjør konfidens og ukjente resultater tydelig synlige.

Ansvarlig personalisering

Fire prinsipper for nyttige opplevelser

Tilpass ut fra kontekst

Prioriter preferanser og atferd kunden selv har vist; bruk utledede signaler bare når de gir relevant og målbar verdi.

Unngå stereotypier

Ikke utled produkter, interesser eller kommunikasjonsstil bare ut fra en estimert kjønnsgruppe.

Mål trinn for trinn

Ikke gå ut fra at berikede data forbedrer resultatet; sammenlign med et nyttig nøytralt alternativ.

Ha alltid en reservevei

Støtt ukjente verdier, rettelser og arbeidsflyter som ikke er avhengige av det utledede resultatet.

Implementeringsprosess

Vurder arbeidsflyten i seks trinn

  1. 01

    Definer et legitimt formål

    Beskriv spørsmålet, målgruppen og forretningsmålet som skal testes, før du legger til en ny egenskap.

  2. 02

    Minimer inndataene

    Send bare feltene som den valgte metoden trenger, og eventuelt landkontekst når den er pålitelig.

  3. 03

    Bevar usikkerheten

    Lagre konfidens, ukjente resultater og andre nyttige signaler i stedet for å tvinge alle poster inn i en gruppe.

  4. 04

    Lag et nøytralt alternativ

    Sørg for at opplevelsen er nyttig når data mangler, konfidensen er lav eller resultatet må rettes.

  5. 05

    Test med en kontrollgruppe

    Sammenlign en avgrenset kampanje med det nøytrale alternativet, og fastsett måltall og testperiode på forhånd.

  6. 06

    Vurder effekt og lagringstid

    Kontroller både gevinster og negative virkninger, ta imot rettelser, og slett utledede data når de ikke lenger trengs.

Illustrasjon av ansvarlig dataanalyse
Rapporter dekning og usikkerhet sammen med resultatene.

Mål effekten

Mål mer enn konverteringsraten

I tillegg til det valgte forretningsmålet bør du følge dekning, ukjente resultater, poster med lav konfidens, forespørsler om retting og reservasjoner. Dokumenter testperiode og utvalgsstørrelse, slik at et begrenset resultat ikke tolkes som en generell konklusjon.

Resultat
Hovedmåltall fastsatt på forhånd
Dekning
Andel poster med resultat og ukjente poster
Kvalitet
Fordeling av konfidens og rettelser
Konsekvenser
Klager, reservasjoner og negative virkninger

Velg implementeringsmetode

Start med et lite utvalg som kan kontrolleres

Personvern og lagring

Behold bare de dataene og den tilgangen som trengs

Send bare verdiene som den valgte metoden trenger, begrens tilgangen til API-nøkler og resultater, og bestem hvor lenge estimerte data skal beholdes i systemene dine, og hvordan de kan rettes ved behov. Ifølge den publiserte personvernerklæringen 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.

Vanlige spørsmål

Spørsmål om navnebaserte data i markedsføring

Hva er navnebaserte kjønnsdata?

Det er et signal som estimeres ut fra mønstre knyttet til et navn, noen ganger sammen med landkontekst. Det er ikke en bekreftet identitet og heller ikke kjønnsidentiteten personen selv har oppgitt.

Forbedrer et estimert kjønn markedsføringen automatisk?

Nei. Resultatet avhenger av målgruppe, budskap, kanal, datakvalitet og testdesign. Behold en nøytral kontrollgruppe, og mål hele arbeidsflyten.

Bør produktanbefalinger baseres bare på et estimert kjønn?

Nei. Det kan forsterke stereotypier og gi irrelevante opplevelser. Prioriter preferanser kunden selv har oppgitt, og interesser du har observert, når det er mulig.

Hvorfor bør konfidens og ukjente resultater beholdes?

De gjør dekningen og usikkerheten synlig, gjør det mulig å bruke egne regler ved lav konfidens og hindrer misvisende rapportering. Ikke tving ukjente resultater inn i en gruppe.

Hvilken implementeringsmetode bør jeg velge?

REST API passer for arbeidsflyter i applikasjoner, regneark passer for data som skal gjennomgås, og integrasjoner uten kode passer for arbeidsflyter med utløsere og handlinger.

Når bør signalet ikke brukes?

Ikke bruk det som grunnlag for beslutninger om ansettelse, kreditt, helse, prising, tilgang eller andre beslutninger med stor betydning for en person.

Hvilke data fra disse forespørslene lagrer GenderAPI?

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.

Publisert: 16. juli 2025Sist gjennomgått:

Test ansvarlig

Velg en implementering som kan kontrolleres

Start med et legitimt formål, minimale inndata og en nøytral kontrollgruppe.

Se API-dokumentasjonen