Skip to content

gmorso/shopify-tracker-run

Repository files navigation

Shopify sales tracker

Herramienta offline-first para estimar ventas de tiendas Shopify públicas a partir de snapshots repetidos de inventario. Cada ejecución guarda un CSV por tienda en snapshots/ y regenera report.html.

Método

  1. Lee products.json y selecciona las variantes disponibles, ordenadas por created_at/ID. Con --newest N se muestrean siempre las N variantes más nuevas.
  2. Intenta obtener el inventario desde products/<handle>.js. En estas tiendas ese endpoint no entrega inventario fiable, así que el resolver memoriza el método add y usa cart/add.js con cantidad 99999.
  3. Compara snapshots consecutivos. Las bajadas de stock son una cota inferior de unidades vendidas; units_per_day es esa cota dividida por interval_days.

No se deben ejecutar barridos completos: add.js está rate-limited. Muestrear de forma acotada y constante conserva la señal y reduce presión sobre la IP.

Uso

Desde la raíz del proyecto:

python3 -m tracker.cli track --newest 60 --sleep 2

El modo opcional de rotación acepta un fichero con una URL por línea (http:// o socks5://) y cambia de proxy tras cada petición lógica:

python3 -m tracker.cli snapshot scuffers.com --newest 30 \
  --proxy-list /ruta/proxies.txt --requests-per-proxy 1

Los proxies gratuitos son efímeros y pueden colgarse o estar ya bloqueados; hay que validar el fichero antes de cada ejecución. La prueba real y sus resultados están en logs/iprotation_demo.log. WARP no quedó operativo como endpoint local en este macOS, por lo que no se presenta como método soportado.

track hace el snapshot de todas las tiendas de stores.txt y luego escribe report.html. Para operar por separado siguen disponibles snapshot, estimate y report.

El informe oscuro es de ancho completo. El resumen superior agrega unidades, ingresos, ciegos y units_per_day; cada tienda muestra además su interval_days, OOS y cambios, y la tabla de top-movers muestra unidades, ingresos, units_per_day e intervalo medido por mover.

Interpreta units_per_day como una velocidad mínima observada, no como ventas exactas. blind cuenta variantes cuyo stock no pudo resolverse; OOS marca una transición de disponible a stock cero.

Programación

Se recomienda muestrear 2–4 veces al día. Por Nyquist, si la cadencia es demasiado baja una reposición puede comerse la evidencia de varias ventas entre dos lecturas; más puntos reducen esa ambigüedad sin convertir el proceso en un barrido.

El wrapper run_tracking.sh activa .venv si existe, entra en el proyecto y escribe en logs/tracking-YYYYMMDD.log. Para ejecutarlo dos veces al día:

0 9,21 * * * /Users/gonzalomorsogranero/Desktop/2-BUSINESS-INTELLIGENCE/shopify-sales-tracker/run_tracking.sh

Limitaciones

  • La estimación es una cota inferior: reposiciones, ventas simultáneas y productos nuevos pueden ocultar unidades.
  • Cuando el inventario no tiene tope observable, la variante queda blind y no contribuye a la velocidad.
  • cart/add.js está rate-limited: hay que muestrear, no barrer el catálogo.
  • Este pipeline no hace descubrimiento ni curación de tiendas Shopify ES; queda pendiente para iter4 y requiere red.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors