Reseñas de App Store a BigQuery

App Store Connect le da una valoración y una lista. Nunca le dirá que siete tiendas están entre 4,4 y 4,7 mientras Japón está en 1,6, porque no tiene forma de poner esos números uno junto al otro. En BigQuery eso es un GROUP BY sobre una columna que ya tiene, y son cinco líneas de SQL.

Apple archiva cada reseña de App Store bajo una tienda, y Reviewflowz escribe esa tienda en cada fila como país. Así el país es un dato real y no una suposición a partir del idioma, y un problema con forma de mercado tiene una forma que se puede consultar.

Esa forma es el diagnóstico. Un fallo general se lee como todos los países cayendo a la vez. Una cadena traducida que ya no cabe en su botón, o un cuadro de búsqueda que dejó de aceptar texto en japonés, se lee como un solo país cayendo mientras el resto no se mueve. Qué país es le dice a qué equipo llamar.

El siguiente paso es una cláusula WHERE, porque el texto completo de la reseña es una columna corriente. Cuente las reseñas que mencionan la búsqueda desde el primero de mes, divididas por país, y tiene el informe de fallo antes de que nadie lo abra.

No existe un destino de BigQuery gestionado en el que hacer clic, y esta página no va a fingir que sí. Lo que Reviewflowz le da es una Google Sheet en su propio Drive que mantiene al día: una nueva reseña de App Store es una nueva fila en menos de media hora, una reseña editada actualiza su fila, y una reseña que Apple retira pierde su fila.

BigQuery lee una Google Sheet respaldada en Drive como una tabla externa. Un solo CREATE EXTERNAL TABLE contra la URL de la hoja y app_store_reviews ya existe en su dataset, se consulta como cualquier otra tabla, y está al día en el momento de la consulta porque lee la hoja, no una copia. Nada que programar, nada que mantener vivo.

Si prefiere una tabla nativa particionada, la Review API es el otro camino. Consúltela periódicamente o use el webhook, y cárguela con el job que ya usa para cualquier otra fuente. Es trabajo que su equipo de datos escribe una vez, y llamarlo job en vez de casilla es precisamente la idea.

En cualquiera de los dos casos, el historial viene incluido. En un plan de pago, un clic carga todas las reseñas de App Store anteriores, así que la línea de tendencia empieza completa en lugar de llenarse durante el trimestre siguiente. Conecte la ficha el martes por la mañana y esa misma tarde puede consultar tres años de reseñas.

La tabla vive en su proyecto de Google Cloud, en la región que eligió, bajo el IAM que ya gestiona y la política de retención que ya definió. Dar acceso a un data scientist son los mismos clics que para cualquier otro dataset, y retirarlo son los mismos clics a la inversa.

Usted decide qué sale. Elija las fichas de App Store y, por cada una, las tiendas. Deje la lista de países vacía y se incluyen todos los mercados en los que vende la aplicación, o indique Japón y Alemania y solo llegan esas filas. Añada un filtro de puntuación y la tabla solo guarda de una a tres estrellas.

Así el equipo de localización recibe un dataset con solo sus mercados sin que nadie mantenga un filtro, y el responsable de soporte recibe uno con solo las puntuaciones bajas, desde la misma cuenta y las mismas fichas. Dos alcances alimentando dos tablas es una configuración normal, no un apaño.

Algo que conviene saber antes de dimensionar nada: el volumen de reseñas de App Store no se reparte de forma uniforme. Se acumula en las horas posteriores a un lanzamiento y en los días posteriores a una selección destacada, así que una tabla que parece tranquila todo el mes reúne la mayoría de sus filas en dos tardes.