Avaluació del risc de pèrdua de clients amb SQL i aprenentatge automàtic

Inici » Pitó » Avaluació del risc de pèrdua de clients amb SQL i aprenentatge automàtic

La rotació de clients és un d'aquests assassins silenciosos de beneficis que erosiona lentament el creixement si no es mesura correctament i s'actuï a temps. La bona notícia és que avui es poden crear models robustos de risc de rotació directament amb SQL sobre el magatzem de dades, combinant tècniques clàssiques d'aprenentatge automàtic, serveis al núvol gestionats i mètriques empresarials molt pràctiques.

Aquesta guia us guiarà de principi a fi a través de l'avaluació del risc de rotació amb SQL en diferents escenaris: des de l'ús d'Amazon Redshift ML i Amazon SageMaker per entrenar models amb SQL pur, fins a la creació de models de regressió logística i rotació de clients en esdeveniments web, fins a tècniques més avançades com l'ajust d'hiperparàmetres i la gestió de dades desequilibrades (rotació de clients vs. no rotació) inspirades en fluxos de treball basats en Python. L'objectiu és mostrar-vos, en detall, com passar de dades en brut a puntuacions de risc accionables que els vostres equips de màrqueting, èxit del client i finances puguin utilitzar realment.

Per què l'avaluació del risc de rotació amb SQL és important per a la vostra empresa

Predir quins clients és probable que marxin és un dels casos d'ús amb un retorn de la inversió més alt. per a l'aprenentatge automàtic aplicat i l'analítica. Perdre un client sol ser molt més car que retenir-lo, i les petites millores en la retenció tenen un impacte desproporcionat en els ingressos i la rendibilitat a llarg termini.

SQL juga un paper central en aquest viatge perquè la majoria de les dades transaccionals, de comportament i de clients ja resideixen en bases de dades i magatzems de dades al núvol; un visió general dels sistemes d'emmagatzematge de dades ajuda a entendre com aprofitar-los. Si els vostres equips poden crear, entrenar i implementar models de rotació directament des de SQL, eviten les exportacions constants de dades, el canvi d'eines i les pipelines d'enginyeria complexes, cosa que redueix dràsticament el temps de generació de valor.

Les plataformes de núvol modernes ara desdibuixen la línia entre l'analítica i l'aprenentatge automàtic.Serveis com Amazon Redshift ML permeten als analistes i desenvolupadors de dades crear, entrenar i utilitzar models d'aprenentatge automàtic a partir d'instruccions SQL familiars, alhora que continuen confiant en serveis totalment gestionats com Amazon SageMaker i SageMaker Autopilot. Això vol dir que podeu gestionar models de rotació sense convertir-vos en un enginyer d'aprenentatge automàtic a temps complet.

A més de la tecnologia, l'anàlisi de la rotació de clients ha d'estar estretament lligada a la realitat empresarial.: com defineixes un client "actiu", quins senyals indiquen risc, quin llindar d'inactivitat importa (30, 60, 90 dies...) i quant estàs disposat a invertir en campanyes de retenció basades en el risc previst. Les tècniques que tractarem són prou flexibles per adaptar-se a indústries molt diferents: banca, telecomunicacions, SaaS, comerç electrònic i més.

Ús d'Amazon Redshift ML per crear models de rotació i risc amb SQL

Amazon Redshift ML és una gran il·lustració de com portar l'aprenentatge automàtic allà on ja hi ha les vostres dades.Et permet crear, entrenar i implementar models mitjançant ordres SQL dins d'Amazon Redshift, mentre que Amazon SageMaker fa la feina més pesada en segon pla.

A la pràctica, Redshift ML exposa el model entrenat com una funció SQL. que podeu invocar consultes, quadres de comandament i treballs ETL. Per a casos d'ús de rotació i risc, això vol dir que podeu integrar perfectament prediccions com ara "client d'alt risc", "probabilitat d'impagament" o "probabilitat de rotació" als vostres informes i canals de dades estàndard.

Sota el capó, Redshift ML es basa en Amazon SageMaker AutopilotL'Autopilot explora automàticament múltiples algoritmes i hiperparàmetres, entrena i ajusta els models candidats i selecciona el millor tenint en compte el vostre objectiu i les vostres dades. Manteniu la visibilitat i el control totals, però us salteu la major part de la fontaneria d'aprenentatge automàtic de baix nivell.

El resultat final és una experiència de desenvolupador familiar: escriviu una instrucció SQL CREATE MODEL a sobre de les taules Redshift, apunteu a un cub S3 per a artefactes intermedis i, quan s'ha acabat l'entrenament, obteniu una funció escalar SQL que es pot utilitzar per a la inferència a escala a tot el vostre magatzem.

Exemple de principi a fi: risc de crèdit i predicció de rotació de clients a Redshift

Per fonamentar els conceptes, repassem un exemple concret basat en el risc financer.Tot i que la variable objectiu en aquest cas és el risc de crèdit (alt vs baix), el flux de treball és idèntic a una predicció clàssica de rotació de clients: heu etiquetat les dades històriques, entreneu un classificador binari i, a continuació, puntueu els clients nous o existents a demanda.

El conjunt de dades d'exemple prové del repositori d'aprenentatge automàtic de la UCI i inclou 1,001 registres, cadascun dels quals descriu un client bancari amb 14 atributs relacionats amb el seu perfil financer i la seva relació amb la institució. Tot i que de mida modesta per als estàndards moderns, és suficient per il·lustrar el procés des de les dades en brut fins al model SQL implementat.

Els atributs (característiques) clau d'aquest conjunt de dades cobreixen tant el comportament demogràfic com el financer:

• comprovació existent: estat del compte corrent existent.
• durada: mesos de relació o durada del crèdit.
• import de crèdit: import del crèdit sol·licitat.
• estalvis: nivell d'estalvi actual.
• ocupació des de: durada de l'ocupació actual.
• sexe: gènere del client.
• estat: estat civil.
• edat: edat del client.
• habitatges: situació de l'habitatge (propi, de lloguer, etc.).
• crèdits existents: nombre de crèdits existents.
• treball: situació laboral.
• tipus de feina: tipus de feina.
• dependents: nombre de persones a càrrec.
• risc: variable objectiu; indica si el client es considera d'alt risc.

La variable objectiu, el risc, és binària, per tant, aquest és un problema clàssic de classificació binària. Podeu pensar que risc = TRUE és anàleg a una etiqueta de rotació, on voleu identificar els clients que probablement incompliran o marxaran per poder actuar de manera proactiva.

Malgrat el conjunt de dades reduït, la configuració reflecteix un flux de treball d'aprenentatge automàtic del món real.: encara divideixes les dades en conjunts d'entrenament i d'inferència, defineixes un esquema adequat a Redshift, crees un bucket S3 per a dades d'entrenament i artefactes i configures un rol IAM amb accés a S3 i SageMaker. En producció, simplement escalaries això amb més files i conjunts de funcions més rics.

Preparació de l'entorn i les dades de Redshift

Abans d'entrenar qualsevol model, cal assegurar-se que el clúster Redshift i els permisos estiguin al seu lloc.Podeu crear el clúster a través de la consola de gestió d'AWS o utilitzar una plantilla de CloudFormation que automatitza la configuració de xarxa i seguretat.

Quan es fa el provisionament a través de la consola, normalment es tria un tipus de node i un recompte. (per exemple, dc2.large amb dos nodes per a una demostració), definiu un port de base de dades, un nom d'usuari i una contrasenya mestres i, sobretot, adjunteu un rol IAM que concedeixi al clúster accés al bucket S3 on resideixen els fitxers CSV d'entrenament i inferència.

Si preferiu la infraestructura com a codi, una plantilla de CloudFormation pot fer girar el clúster Redshift. juntament amb els seus grups de seguretat, grup de subxarxa i rol IAM alhora. Des de la perspectiva del modelatge de risc de rotació, la part important és simplement que el clúster pugui llegir i escriure al cub S3 designat.

Un cop el clúster estigui en execució, aneu a l'editor de consultes Redshift.Des d'allà us connecteu a la base de dades, verifiqueu les vostres credencials i comenceu creant dues taules: una per a l'entrenament (clients etiquetats històricament) i una altra per a la inferència (registres que utilitzareu més endavant per provar el rendiment del model).

L'esquema de la taula d'entrenament reflecteix fidelment l'estructura CSV:

• Columnes de text per a atributs com ara existentchecking, estalvis, ocupaciódesde, sexe, estatus, habitatge, feina i tipus de feina.
• Columnes numèriques per a la durada, l'import del crèdit, l'edat, els crèdits existents i els dependents.
• Un risc de columna booleana, utilitzat com a objectiu a predir.

La càrrega de dades es gestiona mitjançant l'ordre Redshift COPY, que extreu dades de S3 mitjançant el rol IAM, especifica el format CSV, la gestió de la capçalera i el delimitador, i omple les taules d'entrenament i d'inferència. Després que les operacions COPY es realitzin correctament, podeu consultar l'arbre d'objectes a l'editor per confirmar les taules i el recompte de files.

Creació i entrenament d'un model Redshift ML amb SQL

Amb les dades al seu lloc, el següent pas és entrenar un model Redshift ML mitjançant una instrucció CREATE MODEL.Aquí és on SageMaker Autopilot entra en joc per provar múltiples algoritmes i hiperparàmetres candidats per al vostre problema de classificació binària.

L'ordre CREATE MODEL selecciona totes les columnes de predictor rellevants des de risk_prediction_training, designa la columna de risc com a TARGET i defineix el nom de la funció SQL que s'utilitzarà més endavant per a la inferència sobre el vostre magatzem de dades.

Calen dos paràmetres clau: IAM_ROLE i S3_BUCKETEl rol IAM ha de permetre llistar i llegir des del cubell S3, i Redshift i SageMaker utilitzen el cubell S3 per intercanviar dades d'entrenament i artefactes del model. També podeu especificar un MAX_RUNTIME en segons per limitar el temps que Autopilot pot experimentar.

És habitual tenir problemes en la relació de confiança la primera vegadaSi SageMaker no pot assumir el rol IAM associat amb el vostre clúster Redshift, l'ordre CREATE MODEL fallarà. Aleshores, haureu d'ajustar la política de confiança del rol per incloure sagemaker.amazonaws.com com a principal de servei de confiança.

Si existeix un model anterior amb el mateix nom, el podeu eliminar utilitzant DROP MODEL abans de recrear-lo. Això us permet iterar sobre la vostra estratègia de modelització o modificar la configuració sense omplir l'entorn amb models obsolets.

Monitorització de l'entrenament i validació del model Redshift ML

El temps d'entrenament variarà segons la mida de les dades i els límits de temps d'execució, però per al conjunt de dades de risc de crèdit de mostra podeu esperar una hora. Durant aquest temps, podeu comprovar l'estat i les metadades del model executant SHOW MODEL amb el nom del model.

MOSTRA EL MODEL revela informació clau com ara l'estat de l'entrenament (per exemple, ENTRENANT, PREPARAT), l'algoritme seleccionat, la mètrica objectiva i les puntuacions de validació. Per a la classificació binària, una de les mètriques crucials sovint és la puntuació F1, que va de 0 a 1 i equilibra la precisió i la recuperació.

Un cop l'estat del model sigui READY (Preparat), podeu començar a avaluar el seu rendiment predictiu. utilitzant el conjunt de dades d'inferència separat que el model no ha vist mai durant l'entrenament. Això reflecteix un escenari del món real on els nous clients es puntuen sobre la marxa.

Una primera comprovació senzilla és calcular la precisió general. Això es fa executant una consulta SQL que: extreu l'etiqueta de risc real, crida la funció del model (per exemple, func_risk_prediction_model) per obtenir l'etiqueta prevista, marca les prediccions correctes i incorrectes i, a continuació, agrega per calcular num_correct dividit pel total.

Més enllà de la precisió bruta, podeu calcular distribucions de risc agregades sobre el conjunt d'inferènciesPer exemple, podeu comptar quants clients s'assignen a cada categoria de risc (alt, baix, indeterminat) per entendre el comportament del model i quants casos es marcarien per a una revisió posterior o accions de retenció proactives.

Definició de les característiques del comportament del client per als models de rotació de clients SQL

Passant del risc de crèdit a la rotació real, s'apliquen els mateixos principis d'aprenentatge automàtic.: necessiteu dades històriques etiquetades i funcions significatives que capturin com es comporten i evolucionen els clients al llarg del temps. Per al comerç electrònic o els productes digitals, això normalment significa agregar mètriques de compra i interacció per client.

Un model típic de rotació de SQL comença a partir d'una taula d'esdeveniments o transaccions web., on cada fila representa una compra o un esdeveniment comercial amb camps com ara marques de temps, identificadors de comanda, preus i quantitats de productes i identificadors d'usuari.

A partir d'aquests esdeveniments en brut, podeu dissenyar característiques de comportament potents. que resumeixen l'historial d'un client:

• total_de_compres: nombre total de compres realitzades per client.
• ingressos_totals: ingressos acumulats generats per aquest client.
• valor_mitjà_de_comanda: valor mitjà de la cistella; ingressos_totals dividit pel total_de_compres.
• vida_del_client: dies entre la primera i l'última compra.
• dies_des_l'última_compra: antiguitat, mesurada en dies des de la compra més recent fins a una data de referència.
• freqüència_de_compra: nombre de mesos diferents en què el client ha comprat, capturant la regularitat.

Aquestes característiques són crucials perquè la rotació rarament és aleatòriaEls clients que compren cada cop menys sovint, gasten menys i ignoren el vostre màrqueting solen enviar senyals clars que podrien estar a punt de marxar. Capturar la freqüència, la recència i el valor monetari (el clàssic trio RFM) en SQL sol ser el primer pas.

Tot això es basa en un identificador de client fiable.En moltes configuracions d'anàlisi digital, un ID d'Experience Cloud (ECID) o un ID similar emmagatzemat en un camp com ara identityMap.id és el que permet unir esdeveniments entre sessions i dispositius en un únic historial de clients.

Requisits de dades i suposicions per a la modelització de rotació basada en web

Per entrenar un model de churn directament des d'esdeveniments web, el conjunt de dades ha de complir certs requisits mínims.Cada fila ha de representar una transacció o un esdeveniment de compra amb prou detall per ser agregat a les característiques a nivell de client.

Els camps obligatoris típics inclouen:

• identityMap.id: un identificador de client estable entre sessions.
• producteLlistaArticles.preuTotal: cost total dels articles per transacció.
• producteLlistaItems.quantitat: quantitat total d'articles.
• data i hora: data i hora de l'esdeveniment en un format compatible amb funcions de data/hora com ara DATEDIFF (per exemple, YYYY-MM-DD HH:MM:SS).
• comerç.comanda.IDcompra: un valor diferent de nul que confirma una compra completada.

La profunditat històrica és importantPer distingir entre la inactivitat temporal i la rotació real, necessiteu prou mesos de dades per veure diversos cicles de compra per client, especialment en verticals amb intervals de compra llargs (viatges, assegurances, contractes B2B, etc.).

El model també depèn d'una definició clara i operativa de la rotació.Una regla pràctica i habitual per al comerç electrònic és considerar que un client ha estat abandonat si no ha comprat en els darrers 90 dies respecte a una data de referència. Aquest llindar es pot adaptar (30, 60, 180 dies) en funció del vostre cicle de compra normal.

Un cop el conjunt de dades està estructurat i les suposicions són clares, podeu utilitzar SQL per crear etiquetes. (abocats vs. no abocats) comparant days_since_last_purchase amb el vostre llindar i després generant la taula d'entrenament que alimenta la regressió logística o un altre algorisme de classificació.

Construint un model de regressió logística de rotació amb SQL

La regressió logística és una opció natural per a la predicció de rotació amb SQL perquè genera probabilitats entre 0 i 1 i sovint és compatible de forma nativa o mitjançant extensions d'aprenentatge automàtic en bases de dades analítiques modernes i plataformes de dades de clients.

El procés de modelització normalment es desenvolupa en tres fases: enginyeria de característiques, assignació d'etiquetes i entrenament de models.

Primer, agregueu els vostres esdeveniments web en files a nivell de client calculant total_purchases, total_revenue, avg_order_value, customer_lifetime, days_since_last_purchase i purchase_frequency. Això es pot fer en una sola instrucció SQL amb GROUP BY i funcions de finestra, o per etapes amb taules intermèdies.

En segon lloc, creeu una etiqueta de rotació basada en una regla d'inactivitat.Per exemple, churned = 1 si days_since_last_purchase > 90, altrament churned = 0. Aquest conjunt de dades etiquetat esdevé la vostra entrada a la rutina d'entrenament de regressió logística, que es pot invocar mitjançant una instrucció SQL CREATE MODEL o una funció específica del proveïdor.

En tercer lloc, entreneu el model de regressió logística especificant quines columnes són característiques i quina columna és l'etiqueta de destinació (de rotació). El motor d'aprenentatge automàtic aprèn coeficients que reflecteixen com cada característica contribueix al risc de rotació, cosa que pot ser molt útil per a les parts interessades del negoci.

La sortida del model sol ser una taula o vista amb una fila per client., incloent-hi les característiques dissenyades i l'etiqueta de rotació. Més endavant, quan utilitzeu el model per a la predicció, obtindreu una columna de predicció addicional que representa l'etiqueta predita (0 o 1) o la probabilitat de rotació.

Avaluació de models de rotació: mètriques que realment importen

L'entrenament d'un model de rotació de clients només és la meitat de la batalla; cal avaluar rigorosament el seu rendiment. abans de desplegar-lo en campanyes de producció. Els marcs de treball d'aprenentatge automàtic basats en SQL sovint exposen ajudants d'avaluació, com ara una funció model_evaluate, que calcula mètriques comunes.

Per a la rotació, és crucial mirar més enllà de la precisió brutaLa precisió simplement mesura el percentatge de prediccions correctes, però en problemes desequilibrats (on la majoria dels clients no abandonen el servei) un model pot ser "precís" i alhora gairebé inútil per al vostre negoci.

Les mètriques clau per a la predicció de la rotació inclouen:

• AUC-ROC: mesura la capacitat del model per distingir els usuaris que renueven dels que no ho fan en tots els llindars de classificació; els valors més propers a 1 indiquen una discriminació més forta.
• Precisió: proporció de persones que preveuen que canvien de client i que realment ho fan; una alta precisió significa menys falses alarmes i una despesa de retenció més eficient.
• Recordar: proporció de clients que realment deixen de comprar i que el model identifica correctament; un bon registre garanteix que no es passin per alt molts clients en risc.
• Puntuació F1: mitjana harmònica de precisió i recuperació, útil quan es necessita un equilibri entre detectar molts errors i evitar massa falsos positius.

En molts projectes de rotació del món real, les parts interessades de l'empresa es preocupen més per la precisió i el record de la classe positiva. (es preveu que els clients abandonaran) que sobre la precisió global. Al cap i a la fi, l'objectiu és orientar les ofertes de retenció de manera eficient, no quedar bé en una única mètrica mitjana.

L'avaluació basada en SQL es fa normalment contra un conjunt de proves reservades. que no s'ha utilitzat per a l'entrenament. Passeu aquest conjunt de dades a la funció model_evaluate o equivalent, obteniu AUC-ROC, exactitud, precisió i recuperació, i després itereu sobre l'enginyeria de característiques, llindars o algoritmes basats en aquests resultats.

Tècniques inspirades en Python per millorar els models de churn

Moltes de les millors pràctiques en la modelització de churn provenen de l'ecosistema més ampli de l'aprenentatge automàtic., on Python i biblioteques com scikit-learn, imbalanced-learn i altres s'utilitzen àmpliament. Els conceptes, però, són transferibles a fluxos de treball centrats en SQL o configuracions híbrides on SQL gestiona la creació de funcions i Python gestiona la modelització avançada.

Un patró comú és començar a explorar la rotació amb un conjunt de dades públic. com ara un CSV de rotació de clients bancaris de Kaggle. Aquests conjunts de dades solen incloure dades demogràfiques (edat, país, sexe), antiguitat del compte, nombre de productes, puntuació creditícia i si el client ha abandonat (ha abandonat).

El flux de treball habitual comença carregant i inspeccionant el conjunt de dades: comprovant el nombre de files i columnes, resumint les característiques numèriques, explorant la distribució objectiu i identificant atributs òbviament irrellevants com ara els cognoms dels clients o els identificadors opacs que no ajudaran a la predicció.

L'exploració visual és especialment útilRepresentar gràficament distribucions i diagrames de caixa de variables contínues (com l'edat o l'antiguitat) dividides per etiqueta de rotació pot revelar ràpidament quines característiques tenen poder explicatiu. Els histogrames de variables categòriques (gènere, país) mostren si certes categories es correlacionen amb una rotació més alta.

Durant aquesta fase exploratòria també busqueu problemes de qualitat de les dades.: valors perduts, valors atípics extrems, categories dominants i patrons sospitosos. Tots aquests factors poden afectar el rendiment del model posterior i poden requerir neteja, limitació o recodificació.

Les variables categòriques són un altre punt crucialEls algoritmes d'aprenentatge automàtic (ML) solen esperar entrada numèrica, de manera que les categories textuals s'han de codificar. Els codificadors ordinals simples assignen categories a nombres enters, cosa que pot funcionar però pot introduir un ordre artificial (per exemple, codis de color on 6 no és "més gran que" 2 en cap sentit significatiu). Les codificacions més sofisticades com la codificació d'un sol punt o la codificació de destinació solen produir millors models, tot i que a costa de més funcions.

Del primer model de rotació fins a una avaluació robusta

Després d'una neteja i codificació bàsiques, es pot entrenar un primer model de churn.—per exemple, un classificador de boscos aleatoris, que és robust, gestiona bé les relacions no lineals i requereix relativament poc escalat de característiques.

A continuació, divideixes les dades en conjunts d'entrenament i de prova (per exemple, 70% entrenament, 30% prova) per simular clients futurs i invisibles. El model s'ajusta al conjunt d'entrenament i s'avalua al conjunt de prova mitjançant mètriques com ara exactitud, precisió, recuperació i puntuació F1.

En aquesta etapa és molt fàcil deixar-se enganyar per xifres d'alta precisió.En problemes de rotació desequilibrada, un model pot aconseguir una gran precisió simplement predient sempre la classe majoritària (no rotació), mentre que amb prou feines detecta els rotadors reals. És per això que la precisió, el record i la F1 específiques de la classe de rotació són molt més rellevants.

La corba ROC i la seva àrea sota la corba (AUC) proporcionen una visió més matisada, mostrant el compromís entre la taxa de veritables positius i la taxa de falsos positius en tots els llindars. Una corba que domina clarament la línia de base diagonal indica un model útil, però, de nou, cal relacionar-ho amb els compromisos cost/benefici empresarials.

Triar la mètrica d'avaluació adequada és una decisió empresarialSi la fidelització és costosa, és possible que preferiu una alta precisió (només dirigir-vos als clients que probablement deixen de comprar). Si perdre un client és extremadament costós, és possible que accepteu més falsos positius i us centreu en el record (atrapar tants clients com sigui possible), fins i tot si això significa contactar amb més clients.

Ajust d'hiperparàmetres i gestió d'etiquetes de churn desequilibrades

Un cop establert un model de churn de referència, els següents grans guanys solen provenir de l'ajustament d'hiperparàmetres.Els hiperparàmetres són valors de configuració externs al procés d'entrenament (nombre d'arbres, profunditat de l'arbre, taxa d'aprenentatge, etc.) que poden afectar dràsticament la qualitat del model.

Un enfocament pràctic és definir un espai de cerca d'hiperparàmetres (una quadrícula o rangs aleatoris per a cada paràmetre) i després explorar un subconjunt de combinacions mitjançant la cerca aleatòria o l'optimització bayesiana. Per a cada configuració candidata, s'executa una validació creuada sobre les dades d'entrenament i s'utilitza una mètrica com la puntuació F1 per comparar-les.

Per a la rotació, F1 sovint és un objectiu millor que la precisió pura. perquè equilibra la precisió i la recuperació, que és el que normalment us importa quan prioritzeu els clients en risc.

Un altre repte important en la modelització de churn és el desequilibri d'etiquetes: normalment hi ha molts més no-churners que churners a les dades històriques. Si no s'aborda, la majoria d'algoritmes aprendran a "anar sobre segur" i predir la classe majoritària la major part del temps.

Hi ha diverses estratègies per gestionar les dades de rotació desequilibrades:

• Sobremostreig de la classe minoritària utilitzant tècniques com SMOTE, ADASYN o SVMSMOTE, que sintetitzen nous exemples minoritaris interpolant entre els existents.
• Submostrant la classe majoritària per reduir el conjunt de dades i alhora fer que les classes siguin més equilibrades (de vegades combinat amb sobremostreig).
• Ús d'algoritmes o embolcalls que gestionen pesos de classe o subconjunts equilibrats internament, com ara boscos aleatoris equilibrats que entrenen cada arbre en una mostra bootstrap equilibrada per classes.

Empíricament, és crucial que el conjunt de proves romangui intacte i desequilibrat., reflectint la distribució real de la producció. Podeu sobremostrar o manipular només el conjunt d'entrenament; en cas contrari, les mètriques d'avaluació seran massa optimistes i no representatives del rendiment del món real.

En molts experiments, utilitzant l'equilibri a nivell d'algoritme (com un bosc aleatori equilibrat) sense canviar les dades d'entrenament en brut ha produït guanys substancials en precisió i F1, de vegades de deu punts percentuals o més. Per a un model de rotació, això es pot traduir en una millor segmentació dels clients en risc i un retorn de la inversió més alt en les campanyes de retenció.

Recordeu que cada punt percentual de millora en la retenció efectiva pot tenir un impacte desmesurat. en els ingressos recurrents i el valor del cicle de vida del client. Detectar amb precisió més clients que deixen de comprar no és l'objectiu final, però us dóna l'avantatge per desplegar ofertes, millores de servei i intervencions personalitzades on més importen.

En definitiva, la combinació de les capacitats d'aprenentatge automàtic (ML) natives de SQL (com ara Amazon Redshift ML i la regressió logística basada en SQL) amb pràctiques sòlides d'aprenentatge automàtic (enginyeria de funcions, mètriques adequades, ajustament d'hiperparàmetres i gestió de desequilibris) us ofereix un conjunt d'eines potent per avaluar el risc de rotació directament allà on resideixen les vostres dades. Tant si opereu en finances, telecomunicacions, comerç electrònic o SaaS, aquestes tècniques us permeten transformar els historials d'interacció en brut en puntuacions de risc de rotació clares sobre les quals els equips de màrqueting i operacions poden actuar amb confiança, estrenyent el bucle de retroalimentació entre l'anàlisi i les decisions empresarials.