SOURCE Inventory Results 001 - APV¶
Fecha: 2026-06-08
Estado: EVIDENCIA REAL PARCIAL REGISTRADA
Scope: tenant
tenant_id: alpuntodeventa
Owner: Gabi / Carlos Canu
Fuente de verdad:
docs/tenants/alpuntodeventa/business-observer/SOURCE-INVENTORY-RESULTS-001.md
1. Objetivo¶
Registrar solo evidencia real observada durante el inventario controlado de
fuentes del Business Observer de APV, sin exponer datos sensibles, sin
copiar credenciales y sin guardar muestras con datos personales.
2. Alcance cubierto en esta corrida¶
Corrida real ejecutada en forma controlada para:
SOURCE-001- fuente:
ecommerce.dbo.VCLIENTES - dominio:
Clientes - focos de esta validacion:
distribucion real de
Estadoy relacion conFecha_Baja - foco adicional de esta validacion:
unicidad real de
Codigonormalizado - foco adicional de esta validacion:
calidad real de
Telefonousado comoWhatsApp - foco adicional de esta validacion: consistencia real de vendedor
- foco adicional de esta validacion:
consistencia real de
Frecuenciay campos por dia de visita
3. Evidencia operativa real¶
Resultado de acceso:
- conexion real ejecutada:
SI - tipo de acceso:
solo lectura - alias canonico utilizado:
mssql:mssql-sgc-ecommerce - contexto tenant requerido para resolverla:
alpuntodeventa - consulta de control previa:
SELECT 1 - resultado de control previo:
OK
Reglas respetadas:
- no se modificaron datos
- no se crearon tablas
- no se tocaron runtimes
- no se imprimieron credenciales
- no se guardaron filas con datos personales
- solo se registraron agregados
4. Query principal ejecutada para Estado¶
sql
SELECT
COALESCE(NULLIF(LTRIM(RTRIM([Estado])), ''), '(NULL/VACIO)') AS estado,
COUNT(*) AS cantidad_total,
SUM(CASE WHEN [Fecha_Baja] IS NULL THEN 1 ELSE 0 END) AS con_fecha_baja_null,
SUM(CASE WHEN [Fecha_Baja] IS NOT NULL THEN 1 ELSE 0 END) AS con_fecha_baja_informada,
MIN(CAST([Fecha_Baja] AS date)) AS primera_fecha_baja,
MAX(CAST([Fecha_Baja] AS date)) AS ultima_fecha_baja
FROM [ecommerce].[dbo].[VCLIENTES]
GROUP BY COALESCE(NULLIF(LTRIM(RTRIM([Estado])), ''), '(NULL/VACIO)')
ORDER BY cantidad_total DESC, estado;
5. Query de control ejecutada para Estado¶
sql
SELECT DISTINCT
COALESCE(NULLIF(LTRIM(RTRIM([Estado])), ''), '(NULL/VACIO)') AS estado_distinto
FROM [ecommerce].[dbo].[VCLIENTES]
ORDER BY estado_distinto;
6. Resultados agregados observados para Estado¶
| Estado observado | Cantidad total | Fecha_Baja null |
Fecha_Baja informada |
Primera Fecha_Baja |
Ultima Fecha_Baja |
|---|---|---|---|---|---|
CLIENTE ACTIVO |
5938 | 5938 | 0 | NULL |
NULL |
CLIENTE DE BAJA |
5372 | 0 | 5372 | 2018-11-16 |
2026-05-27 |
CLIENTE SUSPENDIDO |
91 | 91 | 0 | NULL |
NULL |
Total agregado observado en la vista:
11401clientes
7. Valores distintos observados de Estado¶
Valores reales observados:
CLIENTE ACTIVOCLIENTE DE BAJACLIENTE SUSPENDIDO
Validacion contra lista esperada:
- valores esperados observados:
SI - valores inesperados observados:
NO NULL/VACIOobservado:NO
8. Lectura funcional inicial respaldada por evidencia¶
Lectura observada en esta corrida:
CLIENTE ACTIVOaparece alineado conFecha_Baja = NULLCLIENTE DE BAJAaparece alineado conFecha_Bajainformada en todos los casos observadosCLIENTE SUSPENDIDOaparece conFecha_Baja = NULLen todos los casos observados
Conclusiones respaldadas:
- la taxonomia real de
Estadoobservada coincide exactamente con la regla documental esperada paraSOURCE-001 - no hubo evidencia de estados textuales sorpresa
Fecha_Bajamuestra una relacion fuerte conCLIENTE DE BAJA- la suspension no aparece tratada como baja fechada en esta vista
9. Query principal ejecutada para unicidad de Codigo¶
sql
WITH base AS (
SELECT
NULLIF(LTRIM(RTRIM([Codigo])), '') AS codigo_norm
FROM [ecommerce].[dbo].[VCLIENTES]
),
dup_codes AS (
SELECT codigo_norm, COUNT(*) AS filas_por_codigo
FROM base
WHERE codigo_norm IS NOT NULL
GROUP BY codigo_norm
HAVING COUNT(*) > 1
)
SELECT
COUNT(*) AS filas_totales,
COUNT(DISTINCT codigo_norm) AS codigos_normalizados_distintos,
SUM(CASE WHEN codigo_norm IS NULL THEN 1 ELSE 0 END) AS codigos_nulos_o_vacios,
COUNT(*) - COUNT(DISTINCT codigo_norm) AS exceso_sobre_unicidad,
(SELECT COUNT(*) FROM dup_codes) AS codigos_duplicados_distintos,
(SELECT COALESCE(SUM(filas_por_codigo), 0) FROM dup_codes) AS filas_involucradas_en_duplicados
FROM base;
10. Resultados agregados observados para unicidad de Codigo¶
| Medida | Resultado observado |
|---|---|
| filas totales | 11401 |
| codigos normalizados distintos | 11401 |
| codigos nulos o vacios | 0 |
| exceso sobre unicidad | 0 |
| codigos duplicados distintos | 0 |
| filas involucradas en duplicados | 0 |
Resultado de control:
SELECT 1 AS okejecutado:SISELECT 1 AS okresultado:1- Query
1Bejecutada:NO
Lectura respaldada por evidencia:
NULLIF(LTRIM(RTRIM([Codigo])), '')sostuvo unicidad perfecta en la corrida real observada- la vista devolvio igualdad exacta entre
filas_totalesycodigos_normalizados_distintos - no aparecieron codigos nulos, vacios ni duplicados
- la combinacion
tenant_id + codigo_clientequeda respaldada como clave logica fuerte paraSOURCE-001bajo la canonicalizacion documental vigente
11. Query 3A ejecutada para cobertura de Telefono como WhatsApp¶
sql
WITH base AS (
SELECT
NULLIF(LTRIM(RTRIM([Telefono])), '') AS telefono_norm
FROM [ecommerce].[dbo].[VCLIENTES]
)
SELECT
COUNT(*) AS filas_totales,
SUM(CASE WHEN telefono_norm IS NULL THEN 1 ELSE 0 END) AS telefono_vacio,
SUM(CASE WHEN telefono_norm IS NOT NULL THEN 1 ELSE 0 END) AS telefono_informado
FROM base;
12. Resultados agregados observados para cobertura de WhatsApp¶
| Medida | Resultado observado |
|---|---|
| filas totales | 11401 |
| telefono vacio | 4294 |
| telefono informado | 7107 |
| cobertura informada | 62.3% |
| cobertura vacia | 37.7% |
Lectura respaldada por evidencia:
Telefonoaparece informado en7107filas y vacio en4294- la cobertura observada es util pero no alta para operacion pura de
WhatsApp - el volumen de vacios observado obliga a tratar este campo con semaforo de calidad y no como contacto universal garantizado
13. Query 3B ejecutada para formato de WhatsApp¶
Consulta originalmente pedida para Query 3B, ejecutada con dos ajustes
tecnicos minimos impuestos por el motor real del SGC:
CONCAT(...)reemplazado por concatenacion con+- separador
\explicitado enREPLACEy en el patronLIKE
La semantica funcional del relevamiento se preservo.
14. Resultados agregados observados para formato de WhatsApp¶
Resumen de calidad estructural sobre 7107 telefonos informados:
| Medida | Resultado observado |
|---|---|
largo entre 10 y 13 luego de quitar separadores |
7027 |
largo menor a 10 |
64 |
largo mayor a 13 |
16 |
| con caracteres no habituales | 35 |
Distribuciones mas frecuentes observadas:
| Largo original | Largo sin separadores | Caracteres no habituales | Casos |
|---|---|---|---|
| 11 | 11 | 0 | 5768 |
| 10 | 10 | 0 | 517 |
| 13 | 12 | 0 | 445 |
| 14 | 13 | 0 | 168 |
| 12 | 12 | 0 | 56 |
| 9 | 9 | 0 | 23 |
| 12 | 11 | 0 | 20 |
| 8 | 8 | 0 | 17 |
| 13 | 13 | 0 | 15 |
| 3 | 3 | 0 | 14 |
Ejemplos enmascarados observados:
| Telefono mascarado | Largo original | Largo sin separadores | Caracteres no habituales | Casos |
|---|---|---|---|---|
911******88 |
11 | 11 | 0 | 199 |
911******66 |
11 | 11 | 0 | 116 |
911******99 |
11 | 11 | 0 | 110 |
911******00 |
11 | 11 | 0 | 79 |
911******55 |
11 | 11 | 0 | 75 |
911******68 |
11 | 11 | 0 | 73 |
911******77 |
11 | 11 | 0 | 73 |
911******98 |
11 | 11 | 0 | 68 |
Lectura respaldada por evidencia:
- la mayoria observable cae en formatos controlables de
10a13digitos tras quitar separadores - la dominante real es
11digitos planos, pero convive con variantes de10,12y13, mas un borde pequeno de valores cortos o largos - no corresponde cerrar todavia una normalizacion definitiva porque la heterogeneidad observada sigue siendo real y hay formatos ambiguos
15. Query 3C ejecutada para repetidos de WhatsApp¶
sql
WITH base AS (
SELECT
NULLIF(LTRIM(RTRIM([Codigo])), '') AS codigo_norm,
NULLIF(LTRIM(RTRIM([Telefono])), '') AS telefono_norm
FROM [ecommerce].[dbo].[VCLIENTES]
),
dups AS (
SELECT
telefono_norm,
COUNT(*) AS filas_por_telefono,
COUNT(DISTINCT codigo_norm) AS clientes_distintos
FROM base
WHERE telefono_norm IS NOT NULL
GROUP BY telefono_norm
HAVING COUNT(DISTINCT codigo_norm) > 1
)
SELECT TOP (50)
LEFT(telefono_norm, 3) + REPLICATE('*', CASE WHEN LEN(telefono_norm) > 5 THEN LEN(telefono_norm) - 5 ELSE 1 END) + RIGHT(telefono_norm, 2) AS telefono_mascarado,
filas_por_telefono,
clientes_distintos
FROM dups
ORDER BY clientes_distintos DESC, filas_por_telefono DESC;
16. Resultados agregados observados para repetidos de WhatsApp¶
| Medida | Resultado observado |
|---|---|
| telefonos repetidos distintos | 350 |
| filas involucradas | 760 |
| clientes involucrados | 760 |
| maximo clientes distintos por telefono | 14 |
| maximo filas por telefono | 14 |
Ejemplos enmascarados de repetidos observados:
| Telefono mascarado | Filas por telefono | Clientes distintos |
|---|---|---|
911*11 |
14 | 14 |
9*9 |
7 | 7 |
911******66 |
5 | 5 |
911******48 |
5 | 5 |
911******69 |
5 | 5 |
911******28 |
4 | 4 |
+54********00 |
4 | 4 |
911******91 |
4 | 4 |
Lectura respaldada por evidencia:
- existen repetidos reales de
Telefonoentre clientes distintos Telefonono debe tratarse como identificador unico del cliente- los ejemplos enmascarados pueden repetirse visualmente en la tabla por colision del enmascarado y no implican necesariamente el mismo telefono raw
17. Semaforo recomendado¶
- veredicto de esta validacion ampliada:
AMARILLO
Justificacion:
- se pudo ejecutar una consulta real de solo lectura con evidencia agregada
Telefonotiene cobertura util pero incompleta:7107/11401informado- la mayoria de los valores informados cae en formatos controlables:
7027/7107con largo entre10y13tras quitar separadores - aun asi persisten
4294vacios,350telefonos repetidos entre clientes distintos, valores cortos o largos y35casos con caracteres no habituales - la fuente sirve como base operativa de
WhatsApp, pero requiere normalizacion cuidadosa y no habilita cierre definitivo de formato ni uso como identificador unico
18. Limites de esta evidencia¶
Esta corrida no valida todavia:
- normalizacion definitiva de
WhatsApp - cobertura territorial de
Localidad,ProvinciayZona - cierre fisico final de
customers_sales_ownerycustomers_visit_schedule
19. Confirmaciones de alcance¶
- no se tocaron tablas
- no se crearon scripts
- no se tocaron
Docker,VPSniOpenClaw - no se versionaron secretos
- no se registraron datos personales
20. Query A ejecutada para cobertura de vendedor¶
sql
SELECT
COUNT(*) AS filas_totales,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Codigo_vendedor])), '') IS NULL THEN 1 ELSE 0 END) AS vendedor_codigo_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Codigo_vendedor])), '') IS NOT NULL THEN 1 ELSE 0 END) AS vendedor_codigo_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Nombre_Vendedor])), '') IS NULL THEN 1 ELSE 0 END) AS vendedor_nombre_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Nombre_Vendedor])), '') IS NOT NULL THEN 1 ELSE 0 END) AS vendedor_nombre_informado
FROM [ecommerce].[dbo].[VCLIENTES];
21. Resultados agregados observados para vendedor¶
Corrida real de solo lectura ejecutada el 2026-06-08.
| Medida | Resultado observado |
|---|---|
| filas totales | 11404 |
| vendedor codigo vacio | 0 |
| vendedor codigo informado | 11404 |
| vendedor nombre vacio | 0 |
| vendedor nombre informado | 11404 |
| codigos vendedor distintos | 76 |
| nombres vendedor distintos | 76 |
pares codigo + nombre distintos |
76 |
| codigos con multiples nombres | 0 |
| nombres con multiples codigos | 0 |
Distribucion agregada observada por codigo de vendedor:
- top 5 codigos por cantidad de clientes:
25=2732,41=1295,33=481,32=440,05=415 - no se registraron nombres de vendedor en la documentacion para evitar datos personales innecesarios
Lectura respaldada por evidencia:
Codigo_vendedoryNombre_Vendedoraparecen con cobertura completa en la corrida observada- la relacion
codigo_vendedor -> nombre_vendedorse sostuvo1:1en la vista observada - la relacion inversa
nombre_vendedor -> codigo_vendedortambien se sostuvo1:1en la corrida observada - para
SOURCE-001, el ownership comercial queda utilizable con semaforoVERDEdentro deVCLIENTES
22. Query D/F ejecutadas para frecuencia y dias de visita¶
sql
SELECT
COUNT(*) AS filas_totales,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([CodFrec])), '') IS NULL THEN 1 ELSE 0 END) AS cod_frec_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([CodFrec])), '') IS NOT NULL THEN 1 ELSE 0 END) AS cod_frec_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Frecuencia])), '') IS NULL THEN 1 ELSE 0 END) AS frecuencia_vacia,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Frecuencia])), '') IS NOT NULL THEN 1 ELSE 0 END) AS frecuencia_informada
FROM [ecommerce].[dbo].[VCLIENTES];
sql
SELECT
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([lunes])), '') IS NOT NULL THEN 1 ELSE 0 END) AS lunes_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([lunes])), '') IS NULL THEN 1 ELSE 0 END) AS lunes_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([martes])), '') IS NOT NULL THEN 1 ELSE 0 END) AS martes_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([martes])), '') IS NULL THEN 1 ELSE 0 END) AS martes_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([miercoles])), '') IS NOT NULL THEN 1 ELSE 0 END) AS miercoles_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([miercoles])), '') IS NULL THEN 1 ELSE 0 END) AS miercoles_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([jueves])), '') IS NOT NULL THEN 1 ELSE 0 END) AS jueves_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([jueves])), '') IS NULL THEN 1 ELSE 0 END) AS jueves_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([viernes])), '') IS NOT NULL THEN 1 ELSE 0 END) AS viernes_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([viernes])), '') IS NULL THEN 1 ELSE 0 END) AS viernes_vacio,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([sabado])), '') IS NOT NULL THEN 1 ELSE 0 END) AS sabado_informado,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([sabado])), '') IS NULL THEN 1 ELSE 0 END) AS sabado_vacio
FROM [ecommerce].[dbo].[VCLIENTES];
23. Resultados agregados observados para frecuencia y dias¶
Cobertura observada:
| Medida | Resultado observado |
|---|---|
| filas totales | 11404 |
cod_frec vacio |
0 |
cod_frec informado |
11404 |
frecuencia vacia |
0 |
frecuencia informada |
11404 |
| codigos de frecuencia distintos | 4 |
| etiquetas de frecuencia distintas | 4 |
| codigos con multiples etiquetas | 0 |
| etiquetas con multiples codigos | 0 |
Distribucion agregada observada de cod_frec y frecuencia:
cod_frec |
frecuencia |
cantidad_clientes |
|---|---|---|
FVC001 |
SEMANAL |
11198 |
FVC004 |
EVENTUAL |
166 |
FVC002 |
QUINCENAL |
39 |
FVC003 |
MENSUAL |
1 |
Cobertura observada por dia:
| Dia | Informado | Vacio |
|---|---|---|
| lunes | 9539 | 1865 |
| martes | 9557 | 1847 |
| miercoles | 9585 | 1819 |
| jueves | 9546 | 1858 |
| viernes | 9669 | 1735 |
| sabado | 10508 | 896 |
Valores agregados observados por dia:
- de lunes a viernes solo se observaron
S,NyNULL/VACIO - en
sabadotambien solo se observaronS,NyNULL/VACIO - distribucion observada:
lunes S=866 N=8673,martes S=871 N=8686,miercoles S=844 N=8741,jueves S=897 N=8649,viernes S=877 N=8792,sabado S=8410 N=2098
Cardinalidad agregada observada de dias informados:
FVC001 / SEMANAL:9182clientes con6dias informados; resto con1-5diasFVC002 / QUINCENAL:37clientes con6dias informados y2con1diaFVC003 / MENSUAL:1cliente con6dias informadosFVC004 / EVENTUAL:152clientes con1dia; borde chico con2,3o6dias informados
Lectura respaldada por evidencia:
CodFrecyFrecuenciaaparecen con cobertura completa y mapeo1:1dentro deVCLIENTES- la taxonomia observada de frecuencia es corta, estable y directamente aprovechable para modelado operativo
- los campos por dia no mostraron texto libre sorpresa en esta corrida; solo
se observaron
S,NyNULL/VACIO - aun asi no corresponde cerrar todavia diseno fisico definitivo porque la
cardinalidad por cliente no es uniformemente simple y sigue conviviendo con
otros pendientes de
SOURCE-001
24. Lectura integrada de esta ampliacion¶
Resultado integrado recomendado para esta validacion ampliada:
- vendedor:
VERDE - frecuencia:
VERDE - dias de visita:
VERDEcomo senal util, con cautela de modelado SOURCE-001ampliada:VERDEpara ownership comercial y calendario base
Nota de estabilidad observada:
- corridas previas del mismo
2026-06-08habian observado11401filas y la corrida ampliada de vendedor/frecuencia observo11404 - la diferencia de
+3filas en la misma fecha indica queVCLIENTESdebe tratarse como fuente viva y refuerza la necesidad futura desync_batch_id,extracted_atylast_seen_at
25. Query A ejecutada para cobertura territorial¶
sql
SELECT
COUNT(*) AS filas_totales,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Localidad])), '') IS NULL THEN 1 ELSE 0 END) AS localidad_vacia,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Localidad])), '') IS NOT NULL THEN 1 ELSE 0 END) AS localidad_informada,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Provincia])), '') IS NULL THEN 1 ELSE 0 END) AS provincia_vacia,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Provincia])), '') IS NOT NULL THEN 1 ELSE 0 END) AS provincia_informada,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Zona])), '') IS NULL THEN 1 ELSE 0 END) AS zona_vacia,
SUM(CASE WHEN NULLIF(LTRIM(RTRIM([Zona])), '') IS NOT NULL THEN 1 ELSE 0 END) AS zona_informada
FROM [ecommerce].[dbo].[VCLIENTES];
26. Resultados agregados observados para cobertura territorial¶
Corrida real de solo lectura ejecutada el 2026-06-08.
| Medida | Resultado observado |
|---|---|
| filas totales | 11404 |
localidad vacia |
0 |
localidad informada |
11404 |
provincia vacia |
0 |
provincia informada |
11404 |
zona vacia |
1 |
zona informada |
11403 |
| provincias distintas | 24 |
| localidades distintas | 516 |
| zonas distintas | 365 |
Lectura respaldada por evidencia:
LocalidadyProvinciaaparecen con cobertura completa en la corrida observadaZonaaparece practicamente completa, con solo1fila vacia sobre11404- la cobertura base de territorio queda utilizable para analitica comercial,
pero la cardinalidad alta de
LocalidadyZonaobliga a tratar la normalizacion como pendiente
27. Query B ejecutada para provincias observadas¶
sql
SELECT
COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)') AS provincia,
COUNT(*) AS cantidad_clientes
FROM [ecommerce].[dbo].[VCLIENTES]
GROUP BY COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)')
ORDER BY cantidad_clientes DESC, provincia;
28. Resultados agregados observados para provincias¶
Distribucion principal observada:
| Provincia | Cantidad clientes |
|---|---|
BUENOS AIRES |
7311 |
CABA |
3749 |
SANTA FE |
51 |
CORDOBA |
38 |
MISIONES |
28 |
ENTRE RIOS |
27 |
RIO NEGRO |
19 |
CHUBUT |
18 |
NEUQUEN |
18 |
CORRIENTES |
17 |
Lectura respaldada por evidencia:
- la cartera observada esta fuertemente concentrada en
BUENOS AIRESyCABA:11060 / 11404clientes, equivalente a97.0% - aun asi la vista preserva alcance federal util, con
24provincias distintas observadas - no se observaron
NULL/VACIOenProvincia
29. Query C ejecutada para localidades principales¶
sql
SELECT TOP (100)
COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)') AS provincia,
COALESCE(NULLIF(LTRIM(RTRIM([Localidad])), ''), '(NULL/VACIO)') AS localidad,
COUNT(*) AS cantidad_clientes
FROM [ecommerce].[dbo].[VCLIENTES]
GROUP BY
COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)'),
COALESCE(NULLIF(LTRIM(RTRIM([Localidad])), ''), '(NULL/VACIO)')
ORDER BY cantidad_clientes DESC, provincia, localidad;
30. Resultados agregados observados para localidades¶
Top 10 pares provincia + localidad por cantidad de clientes:
| Provincia | Localidad | Cantidad clientes |
|---|---|---|
CABA |
PALERMO |
303 |
BUENOS AIRES |
JOSE C. PAZ |
281 |
CABA |
RECOLETA |
249 |
CABA |
BELGRANO |
248 |
CABA |
BALVANERA |
233 |
BUENOS AIRES |
SAN MIGUEL |
223 |
CABA |
ALMAGRO |
181 |
CABA |
VILLA CRESPO |
168 |
BUENOS AIRES |
CAMPANA |
165 |
BUENOS AIRES |
VILLA ADELINA |
156 |
Lectura respaldada por evidencia:
Localidadtiene granularidad comercial alta:516valores distintos observados- aparecieron variantes textuales compatibles con necesidad futura de higiene,
por ejemplo
JOSE C. PAZyJOSE C PAZ - aun con esa dispersion, la senal es claramente aprovechable para lectura territorial por cartera
31. Query D ejecutada para zonas principales¶
sql
SELECT TOP (100)
COALESCE(NULLIF(LTRIM(RTRIM([Zona])), ''), '(NULL/VACIO)') AS zona,
COUNT(*) AS cantidad_clientes
FROM [ecommerce].[dbo].[VCLIENTES]
GROUP BY COALESCE(NULLIF(LTRIM(RTRIM([Zona])), ''), '(NULL/VACIO)')
ORDER BY cantidad_clientes DESC, zona;
32. Resultados agregados observados para zonas¶
Distribucion principal observada:
| Zona | Cantidad clientes |
|---|---|
NO DEFINIDA |
1522 |
ZONA 13-JOSE C. PAZ |
265 |
ZONA 01-PALERMO |
236 |
ZONA 01-BALVANERA |
213 |
ZONA 13-SAN MIGUEL |
181 |
ZONA 01-RECOLETA |
175 |
ZONA 01-ALMAGRO |
158 |
ZONA 08-BELGRANO |
154 |
ZONA 15-CAMPANA |
154 |
ZONA 01-VILLA CRESPO |
143 |
Resumen estructural observado de Zona:
| Tipo de valor | Resultado observado |
|---|---|
NO DEFINIDA |
1522 |
NULL/VACIO |
1 |
prefijo ZONA |
9437 |
| texto libre no prefijado | 444 |
Lectura respaldada por evidencia:
Zonamuestra una taxonomia dominante util:9437 / 11404clientes en zonas con prefijoZONA- persiste un bloque importante de
NO DEFINIDA:1522 / 11404, equivalente a13.3% - existe tambien un borde de
444clientes en zonas textuales no prefijadas, normalmente asociadas a provincias o macroterritorios
33. Query E ejecutada para consistencia zona/provincia/localidad¶
sql
SELECT TOP (100)
COALESCE(NULLIF(LTRIM(RTRIM([Zona])), ''), '(NULL/VACIO)') AS zona,
COUNT(DISTINCT COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)')) AS provincias_distintas,
COUNT(DISTINCT COALESCE(NULLIF(LTRIM(RTRIM([Localidad])), ''), '(NULL/VACIO)')) AS localidades_distintas,
COUNT(*) AS cantidad_clientes
FROM [ecommerce].[dbo].[VCLIENTES]
GROUP BY COALESCE(NULLIF(LTRIM(RTRIM([Zona])), ''), '(NULL/VACIO)')
ORDER BY provincias_distintas DESC, localidades_distintas DESC, cantidad_clientes DESC;
34. Resultados agregados observados para consistencia territorial¶
Resumen estructural observado:
| Medida | Resultado observado |
|---|---|
zonas con 1 provincia |
289 |
| zonas con multiples provincias | 76 |
| clientes en zonas multi-provincia | 6365 |
Ejemplos agregados observados de dispersion:
| Zona | Provincias distintas | Localidades distintas | Cantidad clientes |
|---|---|---|---|
NO DEFINIDA |
3 | 137 | 1522 |
ZONA 06-RAMOS MEJIAS |
3 | 2 | 74 |
MISIONES |
2 | 10 | 27 |
CORRIENTES |
2 | 10 | 17 |
ZONA 04-LANUS |
2 | 5 | 111 |
ZONA 13-JOSE C. PAZ |
2 | 3 | 265 |
Lectura respaldada por evidencia:
Zonano funciona como catalogo territorial estrictamente limpio- una parte relevante de las zonas mezcla mas de una provincia o mas de una localidad, por lo que hoy conviene leerla como senal comercial antes que como jerarquia geografica cerrada
- aun asi la señal sigue siendo util porque conserva agrupaciones operativas visibles y dominantes
35. Query F ejecutada para territorio por Estado¶
sql
SELECT
COALESCE(NULLIF(LTRIM(RTRIM([Estado])), ''), '(NULL/VACIO)') AS estado,
COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)') AS provincia,
COUNT(*) AS cantidad_clientes
FROM [ecommerce].[dbo].[VCLIENTES]
GROUP BY
COALESCE(NULLIF(LTRIM(RTRIM([Estado])), ''), '(NULL/VACIO)'),
COALESCE(NULLIF(LTRIM(RTRIM([Provincia])), ''), '(NULL/VACIO)')
ORDER BY estado, cantidad_clientes DESC;
36. Resultados agregados observados para territorio por Estado¶
Distribucion principal observada:
| Estado | Provincia | Cantidad clientes |
|---|---|---|
CLIENTE ACTIVO |
BUENOS AIRES |
3912 |
CLIENTE ACTIVO |
CABA |
1696 |
CLIENTE DE BAJA |
BUENOS AIRES |
3326 |
CLIENTE DE BAJA |
CABA |
2037 |
CLIENTE SUSPENDIDO |
BUENOS AIRES |
73 |
CLIENTE SUSPENDIDO |
CABA |
16 |
Lectura respaldada por evidencia:
- el territorio principal aparece tanto en cartera activa como en cartera de baja, lo que refuerza el valor de preservar clientes no vendibles para lectura historica territorial
- no se observaron vacios de
Provinciani siquiera en estados no activos
37. Semaforo recomendado para territorialidad¶
- veredicto de esta validacion territorial:
AMARILLO
Justificacion:
LocalidadyProvinciatienen cobertura completa y utilidad territorial claraZonatiene cobertura casi completa y una taxonomia operativa fuerte, pero convive con1522casosNO DEFINIDA,1nulo y444valores no prefijados- la concentracion comercial en
BUENOS AIRESyCABAno invalida el uso; al contrario, hace visible el territorio principal real - la dispersion textual de localidades y la mezcla multi-provincia en
76zonas indican que la fuente sirve para analitica territorial, pero no para una geografia perfectamente normalizada sin una capa posterior de higiene
38. Lectura integrada actualizada¶
Resultado integrado recomendado para SOURCE-001 al cierre de esta corrida:
- identidad cliente:
VERDE - estado comercial:
VERDE WhatsApp:AMARILLO- vendedor:
VERDE - frecuencia y dias:
VERDE - territorialidad:
AMARILLO SOURCE-001como base documental y analitica futura:AMARILLOutil y aprovechable, pero todavia no apta para cerrar diseno fisico final sin capa posterior de normalizacion territorial y de contacto