{"id":2532,"date":"2026-04-01T09:10:09","date_gmt":"2026-04-01T07:10:09","guid":{"rendered":"https:\/\/bicontrolling.com\/?p=2532"},"modified":"2026-04-01T09:21:48","modified_gmt":"2026-04-01T07:21:48","slug":"calculando-clientes-nuevos-perdidos-recuperados-con-funciones-window","status":"publish","type":"post","link":"https:\/\/bicontrolling.com\/index.php\/2026\/04\/01\/calculando-clientes-nuevos-perdidos-recuperados-con-funciones-window\/","title":{"rendered":"Calculando clientes nuevos, perdidos y recuperados con funciones WINDOW"},"content":{"rendered":"\n

Introducci\u00f3n<\/h2>\n\n\n\n

Hace ya unos a\u00f1os que Microsoft incorpor\u00f3 a DAX una nueva familia de funciones tabulares muy especiales: las funciones WINDOW<\/strong>. Se trata de funciones conceptualmente muy similares a las funciones hom\u00f3nimas de SQL, dise\u00f1adas para operar sobre conjuntos de datos previamente ordenados y, si es necesario, particionados.<\/p>\n\n\n\n

Hasta ese momento, resolver c\u00e1lculos dependientes de posiciones relativas; el primer cliente, el anterior pedido, el siguiente valor en un ranking, implicaba recurrir a funciones como TOPN<\/code> o RANKX<\/code>, y a iteraciones anidadas.<\/p>\n\n\n\n

Estas funciones no ampl\u00edan realmente la capacidad expresiva de DAX, todo lo que hoy hacemos con estas funciones ya pod\u00eda hacerse antes, pero s\u00ed transforman la forma en que lo escribimos. Simplifican el c\u00f3digo, lo hacen m\u00e1s mantenible y, en muchos casos, m\u00e1s eficiente. Adem\u00e1s, introducen un concepto nuevo y fundamental en el lenguaje: apply semantics<\/strong>, al que seguramente dedicaremos otro art\u00edculo m\u00e1s adelante, que permite que dichas funciones interact\u00faen simult\u00e1neamente con el contexto de fila y el contexto de filtro.<\/p>\n\n\n\n

En este art\u00edculo vamos a aplicar estas funciones a un caso de negocio muy habitual: la identificaci\u00f3n de clientes nuevos, perdidos y recuperados<\/strong>. Un problema cl\u00e1sico en an\u00e1lisis comercial que, gracias a estas funciones puede resolverse hoy con un rendimiento, claridad y precisi\u00f3n muy superiores a los patrones tradicionales.<\/p>\n\n\n\n

Aunque el foco estar\u00e1 en clientes, el patr\u00f3n que construiremos es completamente generalizable<\/strong>. La misma l\u00f3gica puede aplicarse para detectar productos que dejan de venderse, productos reactivados, tiendas que inician o cesan actividad, comerciales que recuperan cartera…<\/p>\n\n\n\n

En los siguientes apartados veremos c\u00f3mo funcionan estas funciones y c\u00f3mo utilizarlas correctamente para construir un patr\u00f3n s\u00f3lido, reutilizable y eficiente.<\/p>\n\n\n\n\n\n\n\n

Entendiendo las funciones WINDOW en DAX<\/h2>\n\n\n\n

Vamos a iniciar nuestra andadura con las funciones WINDOW y a centrarnos en las m\u00e1s importantes y las que primero se introdujeron: INDEX, OFFSET y WINDOW<\/strong>.<\/p>\n\n\n\n

Son funciones tabulares<\/strong>, es decir, nos devuelven una tabla, igual que FILTER, VALUES o ADDCOLUMNS. Su prop\u00f3sito es muy concreto: navegar sobre una tabla ordenada y particionada<\/strong>, es decir, dividida en bloques de filas, para extraer la fila o las filas que nos interesan.<\/p>\n\n\n\n

Una caracter\u00edstica diferencial es que la mayor\u00eda de sus argumentos son opcionales y est\u00e1n dise\u00f1adas para poder indicarlos en cualquier orden. Si nos fijamos en la sintaxis (ver imagen), las tres funciones comparten la misma estructura y funcionan siguiendo siempre el mismo proceso:<\/p>\n\n\n\n

    \n
  1. Toman todas las filas de la tabla que indiquemos en el par\u00e1metro <table><\/code>. Esta ser\u00e1 la tabla fuente<\/strong>.<\/li>\n\n\n\n
  2. Dividen esas filas en particiones seg\u00fan las columnas indicadas en <partition-by><\/code>.<\/li>\n\n\n\n
  3. Ordenan las filas dentro de cada partici\u00f3n seg\u00fan las columnas de <order-by><\/code>.<\/li>\n\n\n\n
  4. Y finalmente, con el primer par\u00e1metro (el \u00fanico obligatorio)<\/strong> decidimos qu\u00e9 fila o filas queremos devolver.<\/li>\n<\/ol>\n\n\n\n
    \"\"<\/a><\/figure>\n\n\n\n

    Pulsar en la imagen para agrandar<\/em><\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Como vemos en la imagen, tenemos adem\u00e1s otro par\u00e1metro opcional, <blanks><\/code>, que permite indicar c\u00f3mo tratar los valores nulos al ordenar. De momento no entraremos en detalle en este y otros par\u00e1metros opcionales que vinieron despu\u00e9s, porque suficiente complejidad tienen ya estas funciones.<\/p>\n\n\n\n

    La diferencia real entre las tres funciones est\u00e1 en el primer par\u00e1metro<\/strong>.<\/p>\n\n\n\n

      \n
    • INDEX<\/strong> solo puede devolver una fila, y lo hace indicando la posici\u00f3n absoluta dentro de la partici\u00f3n: primera fila, segunda fila, \u00faltima fila\u2026<\/li>\n\n\n\n
    • OFFSET<\/strong> tambi\u00e9n devuelve una \u00fanica fila, pero la posici\u00f3n se especifica de forma relativa respecto a la fila actual: una fila anterior, tres filas antes, la siguiente fila\u2026<\/li>\n\n\n\n
    • WINDOW<\/strong> va un paso m\u00e1s all\u00e1 y permite devolver un conjunto de filas, definiendo el l\u00edmite inferior y superior de la ventana. Esos l\u00edmites pueden indicarse tanto en valor absoluto (como INDEX) como en valor relativo (como OFFSET).<\/li>\n<\/ul>\n\n\n\n

      Podemos ver un resumen en la siguiente imagen:<\/p>\n\n\n

      \n
      \"\"<\/figure>\n<\/div>\n\n\n

      Consideraciones respecto al rendimiento<\/h3>\n\n\n\n

      Aunque en general el rendimiento de estas funciones es muy bueno<\/strong>, especialmente cuando necesitamos ordenar por varias columnas con valores discontinuos, conviene tener en cuenta algunos aspectos para no llevarnos una sorpresa, y no olvidar que, como siempre en DAX, cuando trabajamos con modelos exigentes medir el rendimiento de distintas alternativas es parte del trabajo.<\/strong><\/p>\n\n\n\n

      La raz\u00f3n por la cual el rendimiento de estas funciones suele ser excelente, es porque nos permiten trabajar sobre valores ya agregados<\/strong>, y no sobre la tabla de hechos a su m\u00e1xima granularidad<\/strong>. <\/p>\n\n\n\n

      Para quienes conozcan la diferencia entre el Formula Engine<\/strong> y el Storage Engine<\/strong>, el punto clave es que las funciones WINDOW se ejecutan \u00edntegramente en el Formula Engine<\/strong>.<\/p>\n\n\n\n

      Esto implica que el Formula Engine necesita una copia completa de las filas<\/strong> (y columnas) de la tabla que pasamos como par\u00e1metro <table><\/code>. Incluso en modelos import, no reutiliza directamente la estructura interna de VertiPaq, sino que crea sus propias estructuras en memoria (spools)<\/strong> para:<\/p>\n\n\n\n

        \n
      • almacenar los datos de la tabla base,<\/li>\n\n\n\n
      • mapear las particiones,<\/li>\n\n\n\n
      • mantener arrays ordenados dentro de cada partici\u00f3n,<\/li>\n\n\n\n
      • y vincular la fila actual del contexto con su posici\u00f3n en esas estructuras.<\/li>\n<\/ul>\n\n\n\n

        Cuantas m\u00e1s filas y m\u00e1s columnas tenga la tabla de entrada, mayor ser\u00e1 el consumo de memoria y el trabajo del Formula Engine<\/strong>.<\/p>\n\n\n\n

        Por eso, en mi opini\u00f3n, estas funciones son especialmente \u00fatiles cuando la granularidad del c\u00e1lculo est\u00e1 bien definida<\/strong> y no va a ser modificada din\u00e1micamente por el usuario en la visualizaci\u00f3n.<\/p>\n\n\n\n

        En escenarios donde el usuario puede cambiar la granularidad<\/strong>, hay que ser prudente. Dise\u00f1ar un patr\u00f3n con WINDOW que funcione correctamente para cualquier nivel de granularidad puede disparar el n\u00famero de filas que el Formula Engine necesita materializar, y el impacto en el rendimiento puede ser notable<\/strong>.<\/p>\n\n\n\n

        Por \u00faltimo, si trabajamos en modo DirectQuery<\/strong>, las funciones WINDOW pueden ayudar significativamente, ya que es mucho m\u00e1s probable que las queries generadas por el motor utilicen las tablas de agregaciones<\/strong> que hayamos definido. Precisamente por la misma raz\u00f3n que coment\u00e1bamos antes: porque nos permiten trabajar sobre valores ya agregados<\/strong>, en lugar de forzar c\u00e1lculos a la m\u00e1xima granularidad.<\/p>\n\n\n\n

        Modelando el ciclo de vida del cliente en DAX<\/h2>\n\n\n\n

        Antes de meternos en arena, conviene detenerse en lo esencial: este tipo de c\u00e1lculos depende completamente de las reglas de negocio<\/strong> que definan qu\u00e9 entendemos por cliente nuevo, perdido o recuperado. La l\u00f3gica t\u00e9cnica es solo una traducci\u00f3n formal de esa definici\u00f3n. Si la definici\u00f3n cambia, el c\u00e1lculo cambia.<\/p>\n\n\n\n

        Vamos a comenzar por los clientes nuevos<\/strong>, cuya interpretaci\u00f3n suele ser bastante homog\u00e9nea en la mayor\u00eda de organizaciones: consideraremos cliente nuevo a aquel que realiza una transacci\u00f3n por primera vez, sin haber registrado ninguna operaci\u00f3n en ning\u00fan momento anterior a esa fecha. Es decir, su aparici\u00f3n marca el inicio absoluto de su relaci\u00f3n comercial con la empresa. Si la granularidad temporal del c\u00e1lculo es anual, la f\u00f3rmula a implementar ser\u00eda la siguiente:<\/p>\n\n\n\n

        <\/circle><\/circle><\/circle><\/g><\/svg><\/span>