Por ejemplo, el siguiente ejemplo es un producto que analiza los datos de la tienda móvil de los comerciantes de Taobao. El menú "Fuente de tráfico" es el análisis del tráfico de la tienda. En las primeras etapas del desarrollo de la tienda, "gratis en Taobao", "tráfico pago" y "acceso autónomo" pueden respaldar el análisis de los datos de la tienda por parte de los comerciantes. Sin embargo, con el desarrollo continuo del negocio de las tiendas, los requisitos de granularidad para el análisis del tráfico se han vuelto cada vez más refinados, pero la simple división del tráfico ya no puede satisfacer las necesidades del lado comercial. Se espera que una clasificación más detallada del tráfico interno de Taoke ayude a los comerciantes a tener una comprensión más detallada del tráfico de las tiendas, a fin de ajustar las estrategias operativas de acuerdo con los diferentes tamaños de tráfico y promover el desarrollo de datos de ventas en las tiendas.
Situación actual: acceso gratuito a tráfico pago dentro de Taobao
Expectativas: búsqueda gratuita de mi Taobao Taobao, otros escaneos manuales de Taobao micro-Taobao, etc.
Requisito: Cambiar los campos en la tabla de datos "Fuente de tráfico".
Cuando los productos originales no pueden satisfacer el desarrollo comercial actual, para satisfacer las nuevas necesidades comerciales, sirven nuevos escenarios. Tuvimos que cambiar el diseño original del producto y el diseño del campo en la tabla. Cambiar los campos de la "tabla de datos" puede provocar fácilmente conflictos de datos, incluidos conflictos de tipos de datos y conflictos de formatos de datos.
Si no considera el impacto de los conflictos de datos y cómo ser compatible con los datos históricos al cambiar los campos de la tabla, causará problemas con la integridad y coherencia de los datos en el producto. Por ejemplo, en el caso anterior, si no realiza el procesamiento de compatibilidad de datos históricos y elige iniciar la nueva función estadística el 19 de marzo, habrá dos métodos estadísticos diferentes para la división del tráfico: la división de datos de tráfico antes del 19 y la división de datos de tráfico antes del 19 de marzo. división de datos de tráfico el día 19.
Los datos históricos se han convertido en "datos sucios" en cierto sentido, y hay un dicho que dice que "los datos basura entran y salen". Para los resultados del análisis, la calidad de los datos es incluso más importante que los métodos y modelos de análisis. Los resultados de producción combinados con datos sucios tendrán un impacto grave en el negocio e incluso se tomarán decisiones equivocadas, lo que provocará pérdidas indelebles.
Por lo tanto, es necesario que resuelva los conflictos de datos después del "cambio de campo de la tabla", sea compatible con los datos históricos y reduzca el impacto negativo de los cambios en los datos. Entonces la pregunta es, ¿cómo podemos hacerlo compatible con los datos históricos?
01¿Es necesario guardar los datos históricos?
Después de que ocurren conflictos de datos en los campos de cambio de la tabla, podemos pensar en una pregunta antes de la compatibilidad con los datos históricos: ¿Es necesario conservar todos los datos históricos? Echemos un vistazo a los siguientes dos escenarios.
Escenario 1
En una iteración de un comercio electrónico para b producto, el campo "Precio unitario para el cliente" se agregó al menú "Ventas en tienda", luego el precio para el cliente en los datos históricos ¿El precio unitario significa algo para nosotros?
Escenario 2
Diseñamos un conjunto de cuestionarios para contar la situación laboral de los estudiantes universitarios nacionales en diferentes especialidades y revisamos las preguntas después de un período de tiempo para determinar los datos históricos. ¿Lo recopilado es útil para nosotros? ¿Sigue teniendo sentido?
A través de dos escenarios específicos, podemos encontrar que las estrategias de retención de "datos históricos" son diferentes en diferentes escenarios:
El "precio unitario" en el escenario 1 puede ayudar a copiar el precio de la tienda. Compare el precio unitario del cliente histórico con el "precio unitario del cliente" actual para guiar las estrategias de la tienda. En este caso, los datos históricos son muy importantes y deben guardarse.
Sin embargo, existe una contradicción entre la pregunta "¿Cuál es tu país" y "Estudiantes universitarios nacionales" recopilada en el Escenario 2, y esta pregunta se modificó para resolver esta contradicción, por lo que los materiales históricos recopilados para este pregunta Si no es válida, se puede descartar sin reservas.
Los datos históricos son el registro y la retroalimentación de condiciones comerciales pasadas, pero no todos los datos históricos son significativos y no todos los datos históricos deben conservarse. Antes de considerar la compatibilidad de los datos históricos, se recomienda analizar el valor y la importancia de los "datos históricos" para el negocio en función de escenarios reales. Si son datos irrelevantes o incorrectos, simplemente descarte los datos históricos. Para que se guarden los datos históricos, debemos considerar dónde está el conflicto y cómo hacerlo compatible.
Cómo ser compatible con los datos históricos
Después de pensar en el valor y la importancia de los datos históricos, decidimos conservar los datos históricos, entonces, ¿cómo podemos hacerlos compatibles con los datos históricos? ? Primero, es necesario distinguir qué tipo de conflictos de datos serán causados por diferentes cambios en la tabla de datos y luego proponer las soluciones de compatibilidad correspondientes basadas en diferentes situaciones de conflicto.
1. Agregar campos
A menudo nos encontramos con la situación de "agregar campos" a la tabla, como agregar nuevos campos comerciales y agregar nuevos elementos estadísticos.
Si no es compatible, habrá datos nuevos en los campos añadidos, pero no datos históricos. En este caso, debemos determinar si los datos históricos se pueden completar. Si es así, complete los datos históricos; si no se pueden completar, los datos históricos del nuevo campo se mostrarán en blanco.
2. Reducir campos
Cuando se produce "reducción de campos", si no se procesa, los campos reducidos no tendrán datos nuevos, pero sí datos históricos. En este caso, nuestro enfoque es conservar los datos históricos y reducir la visualización en blanco de este campo después de las estadísticas.
3. La lógica o las reglas estadísticas del campo original han cambiado.
Cuando la lógica estadística o las reglas cambian, si no se realiza la compatibilidad de los datos, los resultados de los datos serán diferentes debido a la inconsistencia en los métodos estadísticos de los datos nuevos y los datos históricos. En este momento, es necesario determinar si los datos históricos se pueden convertir de acuerdo con la nueva lógica estadística. Si es posible, volver a estadificar de acuerdo con la nueva lógica, si los datos históricos no se pueden conservar, los cambios en la lógica estadística. debe registrarse.
4. Profundice o combine estadísticas en los campos originales.
Este cambio dará lugar a la relación entre el nuevo campo y el campo histórico, lo que nos obliga a completar los datos históricos. Por ejemplo, explore el campo A hasta un nuevo campo B y un nuevo campo C, y complemente los valores de datos históricos de los nuevos campos B y C de acuerdo con las reglas de exploración.
En escenarios reales, ocurrirán múltiples conflictos de datos al mismo tiempo y la solución adoptada también es una combinación de múltiples soluciones.
Por ejemplo, en el siguiente caso, repetimos el módulo "Gestión de clientes" y descubrimos mediante una investigación que el equipo de ventas interno quería agregar un campo "Cliente WeChat" al menú "Gestión de clientes" y proporcionar Cálculo automático basado en los niveles de clientes. Función "Próxima visita de regreso", por lo que ajustamos el campo "Gestión de clientes".
El formulario se modifica para: agregar los campos "Cliente WeChat" y "Hora de próxima visita de regreso", y reducir el campo "Tiempo de creación". Hay dos situaciones: "sumar un campo" y "restar un campo". Al analizar la importancia de los dos campos "Cliente WeChat" y "Próxima visita de regreso" para los clientes existentes, se puede recopilar la información de contacto de WeChat del cliente y el tiempo específico de la visita de regreso para facilitar que los vendedores realicen negocios, y los datos en los dos campos pueden también se completará. El campo reducido "Tiempo de creación" tiene poco impacto en el negocio y puede descartarse. Con base en las consideraciones anteriores, hemos procesado el menú "Gestión de clientes" como se muestra en la figura.
Después de que la iteración estuvo en línea, el gerente de producto propuso que la "hora de la próxima visita de regreso" mostrara directamente la hora, lo cual no era intuitivo para el equipo de ventas. La "hora de la próxima visita de regreso" se puede procesar aún más para que sea más intuitiva, porque el formato de hora original del campo "hora de la próxima visita de regreso" admite la conversión de la regla actual, por lo que la hora se puede convertir.
Procese la visualización de la "hora de la próxima visita" y calcule la diferencia entre la "hora de la próxima visita" y la hora actual:
Formato estadístico original: aaaa-mm-dd
>Nuevo formato estadístico: revisita x días; atraso x días.
Con el desarrollo de nuestro negocio, nos encontramos con una situación en la que la lógica estadística y las reglas de los campos no se podían convertir. Los elementos opcionales de "Productos intencionales" en "Gestión de clientes" se cambian de "Producto 1, Producto 2, Producto 3" a "Producto 5, Producto 6, Producto 7". Los datos antes y después del cambio no pueden ser simplemente compatibles, pero los datos antes y después del cambio son significativos para el negocio, por lo que necesitamos
Del caso anterior, descubrimos que no solo hay uno Conflicto al cambiar de mesa. Nosotros utilizamos Hay varias soluciones.
03 El valor y la solución de la compatibilidad con datos históricos
Los cambios en los campos de la tabla causarán conflictos entre los datos históricos y los conflictos de datos modificados darán lugar a inconsistencias en los datos a nivel de producto. lo que dará como resultado que los usuarios no puedan comprender los datos de antes y después genera escepticismo o incluso emociones negativas sobre el producto.
Simplemente agregar o restar campos en la tabla tendrá un impacto relativamente pequeño en los usuarios y reducirá la legibilidad del usuario. Por ejemplo, en el caso anterior, agregar o eliminar campos hará que los usuarios confundan algunos casos con datos y otros sin datos, lo que aumenta el costo de comprensión.
Sin embargo, los cambios en la lógica estadística no son sólo una simple cuestión de experiencia del usuario, sino que también pueden tener un impacto real en el negocio. Por ejemplo, los productos opcionales entre los productos previstos mencionados anteriormente han cambiado. Si los datos históricos son incompatibles en el tiempo y explican los cambios relevantes, es fácil para el vendedor juzgar erróneamente que el producto anterior aún se puede vender, lo que eventualmente conducirá a errores en el pedido o incluso a fallas en el envío después de realizar el pedido, lo que traerá consecuencias negativas para el negocio de la empresa.
Se puede ver que el valor de la compatibilidad con los datos históricos radica en resolver esta serie de conflictos de datos, lo que no solo garantiza la coherencia de los datos a nivel del producto, sino que también permite a los usuarios comprender los motivos de los cambios en los datos. y reduce las emociones negativas de los usuarios y los costos de comprensión. Más importante aún, no solo puede ayudar a los usuarios a restaurar sus negocios, sino que también puede servir como guía empresarial para evitar accidentes y pérdidas.
Sin embargo, la compatibilidad de datos históricos no se aplica a todos los escenarios. Cuando implicamos cambios importantes, como cuando los campos de la tabla original se anulan y rediseñan por completo debido a cambios importantes en el negocio, no se recomienda adoptar la solución de compatibilidad anterior. Podemos optar por realizar una transición alternativa entre datos antiguos y nuevos. La tabla original proporciona soporte para datos antiguos y se crea una nueva tabla para admitir la visualización de nuevos campos. Esto completa la transición del negocio de acciones históricas al nuevo negocio. Por ejemplo, si necesita reconstruir todo el proyecto, puede elegir la opción de migración de datos.
Cuando encuentras conflictos en los datos históricos y necesitas ser compatible, ¿puedes juzgar cómo elegir?