Ampliffy - Intranet

» Incidencia Ampliffy

ID	Fecha	Responsable	Estado	Observaciones	Opciones
1279	02/07/2009 11:53:28	Benjamin Coll	Normal	El comercio climatizador ID=2122 tiene 4 clicks de Jedis RCC de Productos NO remunerados para el día 1 de Julio cuando no ha consumido ni el 50% de su presupuesto diario. Ver porqué ha sucedido esto.	Solucionado! +Comentario
03/07/2009 12:59:05	Vicente Arteaga	- Este anunciante tiene oCPA activo (10¤) - El oCPA determinó para todo el día 1 de Julio que los distribuidores&FPs donde se hicieron los clicks debían desactivarse (los pasó a CPC 0), para que no generaran clicks. - Los clicks generados efectivamente tenían un CPC de 0,11¤, y el product los pasó a CPC 0 porque oCPA así se lo indicó. - Aparentemente existe algún momento por el cual un Jedi que debiera tener peso 0, se muestra online, y genera el click. Acciones: - Analizar en qué momento un Jedi que oCPA ha decidido que tenga peso 0, aparece online con peso. Podría venir de los 2s de intervalo por FE que tarda una subida de SHM de Jedis en poner a peso 0 los Creatives. O un BUG en la parte en C de php que pone los Creatives a peso 0. - Analizar porque este comercio que no lleva 30 ventas en los últimos 30 días, está optimizándose su oCPA. - Consensuar con Benji si el product, en el caso de recibir un click que oCPA ha decidido que debe tener cpc 0, no debiera dejar el cpc de las condiciones contractuales (0,11¤ en este caso) - (TEMA APARTE A ESTA INCIDENCIA): El oCPA en algunos momentos he visto que si lleva muy buen oCPA en el último día, vuelve a habilitar este comercio en muchos distribuidores&FPs que tienen un acumulado muy malo de eCPA. Mejorar este comportamiento, para que no lo habilite en muchos distribuidores&FPs, sinó en unos pocos en los que no haya dado recientemente ya una oportunidad para demostrar su eCPA.
1303	15/07/2009 11:57:27	Benjamin Coll	Normal	Maxihobby ID=983. Ver porqué tiene clicks NO remunerados el día 15 de Julio.	Solucionado! +Comentario
16/07/2009 13:07:50	Alex Ripoll	Entra las 0h y 17h generó 66 clicks NO remunerados desde: Productos: 40 Busquedas: 3 XMLRC: 2 TOP5: 7 MapaUltBusquedas: 7 MapaDelWeb: 3 MapaPrdNew: 4 El día 14 llegó a su límite de presupuesto y, en la madrugada del día 15, se asignó a los distribuidores 100% CBN y se le puso el CPC a 0 a todos sus productos. Deduzco que estos clicks no remunerados son debidos a procesos que todavía no habían terminado como las generaciones de las portadas, las generaciones de los mapas y long tail de búsquedas. Lo extraño son los 40 clicks de 'Productos' ya que, cuando el product.php logea con desde='Productos', es porque NO sabe realmente la procedencia del click. He mirado en el log del product pero no encuentro nada extraño a excepción ninguo de estos clicks tiene el dominio asociado (que dominio generó el click). Da la sensación que son de robots pero no lo puedo certificar. Lo que si que he visto es que los links ocultos que ponemos para detectar robots también se generan desde 'Produtos'.
17/07/2009 15:54:14	Vicente Arteaga	El motivo de los clicks de Productos es doble: 1.- Link oculto de Smith. 2.- TB oraculo. Los clicks del Link oculto de Smith NO se cargan en estadisticas.visitas2productos . El motivo es que tienen id_comercio=0, y el script de carga de clicks los detecta y evita cargarlos. Por filosofía, debieran cargarse en BBDD: Tiempo Aprox: 2h (Alex). Los clicks de TB oraculo cuando llaman al product, no están indicando un From concreto, por lo que se clasifican como From "Productos". Se les podría crear un From nuevo, pero CUIDADO al reusar uno de los Froms existentes (Búsquedas,Categorias,...), porque afectan al CTR, y por lo tanto a los resultados de núcleo, a la Máquina de Jedis,... Crear un nuevo From supone: modificar product - 1h Vicente, modificar BBDD y proceso de carga de clicks - 3h Alex, modificar Oraculo - 15m Alex o Vicente. Lo discutimos en la reunión matinal.
27/07/2009 09:57:34	Benjamin Coll	Lo resolveremos después de haber hecho la auditoría de clicks por parte de Vicente.
1309	16/07/2009 17:07:35	Sergio Lopez	Grave	JEDIS: En la página http://www.universaltopmusic.es/ vemos dos jedis uno debajo del otro en la columna de la izquierda que repiten los anuncios. Si refresco la página sigo viendo los mismos anuncios. Verificar que no sea un problema relacionado con ruleta.	Solucionado! +Comentario
16/07/2009 18:42:31	Vicente Arteaga	Existen varios problemas: 1.- En Internet Explorer se veían siempre los mismos anuncios por muchas veces que refrescara. Motivo: IE estaba rechazando las cookies por un tema de seguridad. 2.- Si hay dos códigos de Jedis pegados en una misma página de un afiliado, si ambos tienen bolsas de Creatives similares (mismas Sections, mismas KWs), se repetirán los anuncios. Motivo: I) ambas peticiones al ad_tpl se hacen simultáneamente, cosa que provoca que no se envíe que Creatives se han mostrado en cada módulo, porque todavía no lo sabemos. II) ruleta selecciona siempre los Creatives con mejor peso. Solución: 1.- He copiado y pegado en ad_tpl el código del product.php que soluciona este problema. Falta revisar otros códigos (Widgets por ejemplo): Tiempo Aprox: 2h 2.- Propongo: - Corto plazo: Crear un report que avise a Desarrollo de Negocio de qué Afiliados tienen 2 o más peticiones a los Jedis en una misma página. Con esta información, deberá revisar dichas páginas, y contactar con el afiliado para que cambie el código por una única llamada a los Jedis. Tiempo Aprox: 4h si lo hago bien (detectando correctamente qué es una página vista, y no lo que actualmente usamos) - Largo Plazo: La solución buena es implementar códigos en JavaScript, aunque ese javascript sólo añada un parámetro a la URL del iFrame indicando la cantidad de iFrames que hay.
1322	29/07/2009 11:35:13	Benjamin Coll	Normal	Comprobar y recordar cómo funciona la lógica de las plantillas de Lisi de los Jedis de Productos.	Solucionado! +Comentario
1329	06/08/2009 11:37:14	Vicente Arteaga	Grave	BE12 se ha quedado sin espacio en disco esta madrugada, entre la 1:45 am y la 2:15 am. El culpable del problema fué la modificación que hice ayer para evitar que se cargaran los clicks que Netfilia hizo a un único producto de eBaby. Aunque la modificación aparentemente era muy sencilla, provocó un comportamiento no deseado, y dificil de predecir por el propio comando. Los testeos que hice no dispararon el problema. He resuelto la fuente del problema para evitar que se pueda dar en un futuro (el fichero resultante de una operación podía realimentarse como origen de la propia operación, haciendo que nunca acabe la operación, y que crezca el fichero resultante hasta que deja la máquina sin espacio en disco). A qué ha afectado: - Se ha retrasado ligeramente la carga de clicks - Se han perdido datos de 01:45 am a 02:15 am sobre las peticiones de TCS, las peticiones a shopalladservices.com, las impresiones del Always Running de Impresiones de FGs y el registro unificado de ad_tpl que uso sólo para generar los ficheros de DCS. Medidas a tomar - Hacer que los scripts que han perdido datos sean más robustos: los mecanismos existentes para que no perdieran datos no fueron suficientes: Hacer que el sistema de TCS y shopalladservices sea más robusto y en caso de que BE12 se quede sin espacio en disco, funcione correctamente ó al menos deje los logs disponibles para recargarlos manualmente. Hacer lo mismo para el registro unificado de ad_tpl para el DCS. Tiempo Aprox: 1h (Vicente) Hacer que el sistema de Always Running de Carga de Impresiones de FGs sea más robusto y en caso de que BE12 se quede sin espacio en disco, funcione correctamente ó al menos deje los logs disponibles para recargarlos manualmente. Tiempo Aprox: 1h (Alex)	Solucionado! +Comentario
1330	18/08/2009 12:12:48	Alex Ripoll	Normal	Haciendo pruebas online con el desarrollo ID=3971 he visto que aún estamos generando en la SHM claves relacionadas con el proyecto "Biblia" que son las de tipo 8 y 9. Hay que eliminar estas claves de la generación de SHM ya que el proyecto biblia está parado y no tiene sentido generar estas claves que pueden generar confusión.	Solucionado! +Comentario
24/08/2009 10:54:11	Benjamin Coll	Lo dejamos así hasta nueva orden hasta que veamos qué hacemos con los productos de fabricantes que tenemos de ICECat.
1334	26/08/2009 08:51:03	Sergio Lopez	Normal	Pico de impresiones remuneradas. Verificar a que se debe el pico de impresiones remuneradas generadas ayer a las 23:00hs. Son unas 2.000.000 de impresiones, cuando lo "normal" hubiese sido hacer 600.000 impresiones.	Solucionado! +Comentario
26/08/2009 09:38:03	Alex Ripoll	Los anunciantes que más impresiones han tenido de 22 a 23h son: Google Adsense (Venezuela) (ID=15400) = 123.929 Google Adsense (Perú) (ID=15399) = 153.947 Google Adsense (Estados Unidos) (ID=15406) = 165.958 Google Adsense (Chile) (ID=15395) = 199.957 Google Adsense (Argentina) (ID=15387) = 212.229 Google Adsense (Colombia) (ID=15397) = 218.581 Google Adsense (México) (ID=15386) = 558.406 Total: 1.633.007 Impresiones
27/08/2009 10:04:38	Benjamin Coll	Hay que revisar este tema con Vicente. No tendrían que haber impresiones de Shopall.net, ya que es un distribuidor secundario.
1358	28/09/2009 15:43:54	Sergio Lopez	Grave	Fnac: No está funcionando el ID TCS Unificado en las diferentes fichas de Fnac. Los pedidos siguen viéndose reflejados en la ficha principal (ya no tiene productos asignados online). Se realizó la siguiente prueba: Hemos hecho una prueba de compra para el comercio de Fnac ES (Música) con el producto "Cd Pereza Animales" de referencia 244301 del comercio 16443 Fnac ES (Música), con precio final de 21,41¤ En Watto, el producto que aparece es "Cd Ilusión" de referencia 9405. Esta compra ha quedado registrada como "Pedidos filtrados por Shopall". Necesitamos que Vicente vea exactamente que sucede. Desde Operaciones/Información no se ha podido resolver el problema.	Solucionado! +Comentario
29/09/2009 15:21:17	Vicente Arteaga	Los datos en las tablas del TCS eran correctos. Sin embargo la tabla de caché para Watto no tenía datos correctos. Lanzando la caché de Watto para un día soluciono el problema, así que he lanzado el recacheo para todo el mes. Mañana a primera hora habrá acabado. He estado analizando qué puede haber sucedido, y no encuentro el motivo exacto. Todo apunta a que es un anunciante Arbitrage que usa nuestro TCS, y que eso no esté provocando alguna interacción. No voy a dedicarle más tiempo hasta que vuelva a suceder.
30/09/2009 11:46:35	Vicente Arteaga	Conclusión: Aquí han entrado en juego varios factores: 1.- El motivo por el cual se siguen reflejando ventas en la ficha de Fnac, pese a que ya no tenga productos asignados online, se debe a que durante 120 días siguen contando los clicks que se generaron en dicha ficha. (Considero que esto es correcto) 2.- El sistema que hice para relacionar las transacciones con los clicks estaba asociando la venta no al último click, sinó al primero. Si hay más de 1 click relacionado para una transaccion, la venta podía asignarse a un click, normalmente de otro producto no relacionado con la venta. (Lo he corregido) 3.- Existe un periodo de tiempo mientras se están estableciendo las relaciones entre transacciones y clicks durante el cual los siguientes campos están vacíos: id_canal_ultimo_click, ip_user_ultimo_click, id_from_ultimo_click, id_hit2roi_ultimo_click . Eso podría provocar que el periodo entre dos recacheos de Watto (normalmente se lanza uno al día para todo el mes, y uno cada media hora para el día en curso), la cache de Watto no encontrara el último click relacionado. He revisado el código del cacheador de Watto, y veo que eso provocaría que se clasificara como Watto Friend. Cambios a realizar: 1.- Relanzar el sistema que asocia transacciones y clicks para todo el año 2009. 2.- Evitar que haya ese periodo de tiempo en el cual las relaciones entre transacciones y clicks muestran datos incorrectos para el último click. (Tiempo Aprox: 1h Vicente)
1396	18/11/2009 09:48:59	Benjamin Coll	Grave	HAY QUE HACER LO SIGUIENTE: Validar manualmente que no existan más URLs en el fichero de lighttpd.conf en el formato antiguo. Para tener una alerta temprana de cualquier problema con la configuración del lighttpd he hecho que dos frontends de núcleo y 1 de imágenes se reinicien una vez antes de las 00:00. - cbfe2: se reiniciará a las 23:00 - cbfe30: se reiniciará a las 23:15 - cbfe42: se reiniciará a las 23:05 Vicente Arteaga wrote: > El problema ha venido por: > 1) Atlas tardar 40 minutos de más en avisarnos. > 2) Aparentemente se cambió en algún momento de los últimos dos años la URL de servicio del distribuidor 1921 y no se lanzó el txurrero para actualizarlo en todos los ficheros. > > Qué hay que hacer: > 1) Validar manualmente que no existan más URLs en el fichero de lighttpd.conf en el formato antiguo. > 2) Hacer un sistema que testee que a)no existan dos URLs iguales en el fichero de configuración, b)la URL del fichero no coincide con BBDD y c)avise de cualquier problema durante el mismo día, y que no nos enteremos en el reinicio. > 3) Tirar de las orejas a Atlas por esperar 40 minutos más de lo habitual en llamarnos. Yo ya se lo he remarcado al técnico, pero enviaré un email a Oscar García y a Monty quejándome al respecto. > > Me pondré en ello mañana a primera hora... ahora voy a descansar. > > > > La explicación técnica detallada es: en el fichero de configuración del lighttpd habían dos entradas muy similares, que variaban sólo con el símbolo ^ y $: > > #---------- VirtualHost SieteCruces: 566 ---------- > $HTTP["host"] =~ "compras\.indicesiete\.com" { > ... > } > #---------- /VirtualHost SieteCruces: 566 ---------- > > y > > #---------- VirtualHost SieteCruces.com: 1921 ---------- > $HTTP["host"] =~ "^compras\.indicesiete\.com$" { > ...	Solucionado! +Comentario
20/11/2009 09:47:14	Benjamin Coll	He revisado la mitad del archivo de configuración y hoy remato el resto para finalizar la incidencia.
23/11/2009 12:53:02	Alex Ripoll	Hay 574 URLs que están con el formato antiguo en el fichero de configuración. A excepción de la URL de compras.indicesiete.com que está repetida PERO comentada, no hay ninguna URL más repetida en el fichero. Hemos de hablar con Vicente que hacemos con estas URLs con formato antiguo: si lo dejamos como está o si lanzamos el txurrero para todas ellas o si lanzamos el txurrero desde 0 para todos los SEs.
23/11/2009 12:53:55	Alex Ripoll	Adjunto listado con las 574 URLs que están con formato antiguo. listado_urls_formato_antiguo.txt
30/11/2009 11:00:11	Benjamin Coll	Vamos a dejarlo tal y como está hasta que veamos cómo atacar este problema con calma.
1416	03/12/2009 18:51:36	Vicente Arteaga	Normal	Cada vez que se muere BE2, durante el tiempo que está muerto, damos errores 500 online. Hechos: - Un proceso de FE lee el fichero /etc/resolv.conf - De dicho fichero obtiene una lista de servidores DNS, donde usara un maximo de 3 - Se le puede especificar que use cada servidor DNS, en orden, esperando un minimo de 1 segundo antes de pasar al siguiente. - O se le puede especificar que pregunte en orden aleatorio, esperando un minimo de 1 segundo antes de pasar al otro. - Si alguno de los servidores DNS falla y no responde a las peticiones DNS, cada proceso que intente conectarse tarda 1 segundo mas de lo habitual. - En un servidor web, los procesos que intentan resolver cualquier cosa via DNS (product.php, nucleo) se retrasa 1 segundo por peticion en el peor caso. - Hay actualmente 12 procesos php en cada servidor web. - Si los 12 procesos php estan pendiente de respuesta por parte, por ejemplo de product.php, el servidor web ya no puede dar respuesta y genera errores 500. Creo que la mejor forma de solucionarlo o al menos aliviarlo en la situacion que estamos es: - Instalar un dnscache en cada servidor web, dicho dnscache funcionara exactamente como el dnscache que hay en BE1 y BE2, y provocara que solo 1 de cada 10 segundos haya un retraso de 1 segundo. Tiempo Aprox de implementarlo: 2h Vicente o Alex. Otras opciones: - Instalar un tercer servidor dnscache y activar en todos los FEs la opcion de /etc/resolv.conf "rotate" para que haga un round robin por los 3 servidores: en caso de caer un servidor, 1/3 de las peticiones tardarian 1 segundo de mas. - Hacer un proceso que detecte cuando se ha caido uno de los dos servidores dnscache, y reescriba el /etc/resolv.conf para que solo este el servidor que esta activo ahora mismo. - Separar a nivel de lighttpd dos grupos de procesos php: unos para el ad_tpl, y otros para product.php. De esta manera aseguramos que un problema en unos no afecta a los otros.	Solucionado! +Comentario
1444	18/01/2010 17:51:38	Vicente Arteaga	Normal	Las strings que obtenemos del tráfico orgánico de la red Shopall NO se está almacenando correctamente en BBDD: usan un archivo de configuración que NO se está actualizando desde hace más de 1 año. Habría que: - modificar el script para que acceda directamente a BBDD - asegurarse que está ejecutándose en BE11 a BE14, para garantizar que se procesan todos los logs.	Solucionado! +Comentario
19/01/2010 11:33:57	Vicente Arteaga	Los datos de esta tabla sólo se usa para una herramienta estadística que no creo que se haya usado nunca: - Herramienta estadística: Intra->Technology->Statistics->Eopi (Palabras Clave desde Crawlers) Anteriormente la tabla con los Strings que obtenemos del tráfico orgánico se usaban para: - Mapa Top Búsquedas - Mapa Referencias Dejo la incidencia aquí hasta que le busquemos una utilidad a esta información caótica pero con valor potencial, o decidamos eliminarla.
1523	31/03/2010 15:13:19	Sergio Lopez	Normal	He visto que servimos simultáneamente anuncios de una misma campaña con frecuencia 1. Ejemplo "campaña PAF (728x90 y 300x250) y campaña Alsa (728x90 y 300x250) en Shopall en la misma página vista". Vicente me ha comentado que existen desarrollos pendientes con respecto a esta problemática que entiendo que afecta y mucho en las páginas RCC que repiten un mismo código. Es necesario que se repasen estos desarrollos y se pongan en producción ya que este es otro motivo por el cual nuestra frecuencia no es similar a la de nuestros clientes.	Solucionado! +Comentario
06/04/2010 10:15:56	Benjamin Coll	Identificar los desarrollos en rojo y cerrar la incidencia.
06/04/2010 16:12:56	Vicente Arteaga	Desarrollos: - 3993 (en Rojo): Axioma de No repeticion. A partir de este desarrollo tienen que salir más, que corrijan la problemática que comenta Sergio. Tiempo Aprox: 2h Responsable: Vicente - 3732 (en Verde): Tiempo Aprox: 5h Responsable: Vicente - 4268 (en Rojo): Tiempo Aprox: 7h Responsable: Vicente - 4269 (en Verde): Tiempo Aprox: 16h Responsable: Vicente
1528	06/04/2010 13:11:24	Vicente Arteaga	Normal	El Lunes 12 de Abril analizar los datos de Mundoelectro (ID=15814). Tiene que variar su comportamiento a mejor después de finalizar la tarea con ID=4345.	Solucionado! +Comentario
12/04/2010 13:32:04	Vicente Arteaga	No ha realizado ninguna venta desde el día 7 de Abril. Estoy investigando el motivo.
12/04/2010 16:43:08	Vicente Arteaga	Aparentemente los problemas de rendimiento hacen que se actualice la información online muy pocas veces para este comercio. He dejado un proceso lanzado que me de mayor visibilidad.
13/04/2010 12:48:20	Vicente Arteaga	He abierto una incidencia PCS porque hay productos que hacen link contra una página donde no aparece dicho producto, o donde aparece el producto, pero no se puede comprar. Como ejemplo los dos primeros productos que aparecen en esta búsqueda: http://www.shopall.es/compras/mundoelectro/
15/04/2010 10:14:15	Vicente Arteaga	Hoy ya aparecen los productos correctamente. Mañana analizaré qué tal ha ido las ventas de hoy.
16/04/2010 17:59:50	Vicente Arteaga	Parece que va realizando más ventas, pero debido al parón de ventas entre el día 7 y el 12 es difícil de valorar. Voy a dejarlo más días para poder comparar.
23/04/2010 16:56:36	Vicente Arteaga	Sin el punto 8 online no tiene sentido analizar Mundoelectro. Dejo este tema en pausa hasta que reimplemente el punto 8 online.
25/05/2010 10:19:32	Vicente Arteaga	Benji, deja esta incidencia aquí, pendiente del desarrollo de Vicente con ID=4395
1584	04/10/2010 10:51:35	Sergio Lopez	Grave	Generación de KW's en productos catálogo manual. El viernes 1 de octubre Alvaro modificó el nombre de un producto de catálogo manual de Orange (ID=16050) y a día de hoy todavía no se han actualizado las keywords asignadas por el CDC. El ID de producto único es 100364967 y la URL de la gestión del catálogo: https://intranet.codigobarras.com/productos/index.php?idcat=18634&idcom=16050&nomcat=Orange%20%28fijo%29%20Manual&auto=0 El antiguo nombre era "Nuevo ADSL TDI de Orange" y ahora es "ADSL Máxima Velocidad de Orange".	Solucionado! +Comentario
04/10/2010 13:01:56	Alex Ripoll	Estoy mirando que puede haber pasado. Es muy probable que sea debido a la nueva versión de PHP de BE10 pero tengo que acabar de certificarlo.
04/10/2010 18:21:30	Sergio Lopez	Lo mismo sucede con un producto del El Corte Ingles (parseo) http://www.shopall.es/compras/Blanco_y_Negro_Hits_2010/
06/10/2010 16:30:43	Vicente Arteaga	Alex, probáblemente esta incidencia esté relacionado también con este fallo online: En la biblia, los últimos productos de fabricantes NO tienen KWs. Puedes ver algún ejemplo en: http://www.shopall.com/phones-pdas-gps/savi/ http://www.shopall.com/phones-pdas-gps/p-2920218-Telephone-Plantronics-Savi-Office-Wo350/ http://www.shopall.com/phones-pdas-gps/p-2920100-Telephone-Plantronics-Savi-Office-Wo300-Dect-Headset/
06/10/2010 18:21:20	Alex Ripoll	Ya está solucionado. Era un bug en la librería del CDC que introduje cuando hicimos el desarrollo para generar las palabras clave de la Biblia. Este bug afectaba a productos de anunciantes y a productos de fabricantes de forma aleatoria. Mañana, después de hacer las comprobaciones, se podrá cerrar la incidencia.
07/10/2010 11:45:00	Alex Ripoll	Certifico que a nivel de productos de anunciantes ya está 100% solucionado el problema. Me acabar de comprobar los productos de la Biblia.
07/10/2010 15:38:49	Alex Ripoll	Las claves biblia para los productos de estos fabricantes SI que están en la SHM online pero, sin embargo, es como si el núcleo no las estuviera tratando. He añadido debuging en el núcleo y subido a FE1 para tener un poco más visibilidad.
07/10/2010 16:51:42	Alex Ripoll	El problema de las KW de la Biblia no es de núcleo, es de Nominator. En este caso, ICEcat.biz (USA) ID=16248 no está asignado internamente a www.shopall.com y por eso no aparecen sus productos.
07/10/2010 18:31:36	Alex Ripoll	Ya está solucionado el problema de Nominator y lo que pasaba es que , por razones históricas, no se tenía en cuenta los fabricantes y las asignaciones que habían en la BD ya estaban creadas de hace tiempo. He subido un nuevo código de Nominator que si que tendrá en cuenta los fabricantes y mañana ya se podrá cerrar la incidencia.
10/10/2011 18:00:48	Alex Ripoll	La URL http://www.shopall.com/phones-pdas-gps/p-2920218-Computer-Headsets-Plantronics-Savi-Office-Wo350/ sigue dando problemas y ahora da un error 500. Ha que analizar la petición con un debuger (gdb) y ver en que parte del núcleo se muere.
1622	27/01/2011 09:36:16	Vicente Arteaga	Normal	Jordi tiene dudas de que esté funcionando para todos los casos el proceso que recibe la Query String buscada en Google Search, y asocia dicha Query String a todos los clicks generados en Shopall. 3 Ejemplos donde Jordi ve que no está funcionando: Ejemplo 1: - Día de la discrepacia: 2011-01-26 - Keyword: NOKIA X6 (Phrase) (id_referer = 16357535) - URL keyword: http://www.shopall.es/share-ht/product.php?idd=1711&fr=49&ic=18621&cbcmp=16357535_prd_search&cbsrc= adwords_shopsearch&cbmdm=cpc&fip=-1&pa=149287348&u=http%3A%2F%2Fwww.shopall.es%2Fes_ES%2Fshare-cgi%2Fsearch.ftcb%3F%26tpl%3D ResultadosBuscaLight%26id%3D1711%26lc%3Des_ES%26cv%3D36%26idp%3D142269520%26k%3DTel%25E9fono%2BM%25F3vil%2B Nokia%2BX6%2B8gb%2Bcon%2BContrato%2BParticulares%26tul9%3D1%26lr%3D18 - Clicks desde Adwords: 6 - Strings de búsqueda encontrados: 4 NOKIA X6 OGB AZUL SMARTPHONE (1) NOKIA X6 8GB (1) FOTO NOKIA X6 (1) NOKIA X6 MOVISTAR 8GB (1) --------------------------------------------------------------------------------------------- Ejemplo 2: - Día de la discrepacia: 2011-01-26 - Keyword: NOKIA X6 (Exact) (id_referer = 16357534) - URL keyword: http://www.shopall.es/share-ht/product.php?idd=1711&fr=49&ic=18621&cbcmp=16357534_prd_search&cbsrc= adwords_shopsearch&cbmdm=cpc&fip=-1&pa=149287348&u=http%3A%2F%2Fwww.shopall.es%2Fes_ES%2Fshare-cgi%2Fsearch.ftcb%3F%26tpl%3D ResultadosBuscaLight%26id%3D1711%26lc%3Des_ES%26cv%3D36%26idp%3D142269520%26k%3DTel%25E9fono%2BM%25F3vil%2B Nokia%2BX6%2B8gb%2Bcon%2BContrato%2BParticulares%26tul9%3D1%26lr%3D18 - Clicks desde Adwords: 22 - Strings de búsqueda encontrados: 19 NOKIA X6 (19) --------------------------------------------------------------------------------------------- Ejemplo 3: - Día de la discrepacia: 2011-01-25 - Keyword: NOKIA 2720 (Phrase) (id_referer = 16358271) - URL keyword: http://www.shopall.es/share-ht/product.php?idd=1711&fr=49&ic=18621&cbcmp=16358271_prd_search&cbsrc= adwords_shopsearch&cbmdm=cpc&fip=-1&pa=149287372&u=http%3A%2F%2Fwww.shopall.es%2Fes_ES%2Fshare-cgi%2Fsearch.ftcb%3F%26tpl%3D ResultadosBuscaLight%26id%3D1711%26lc%3Des_ES%26cv%3D36%26idp%3D121948441%26k%3DTel%25E9fono%2BM%25F3vil%2B Nokia%2B2720%2Bde%2BTarjeta%2BOrange%2BParticulares%26tul9%3D1%26lr%3D18 - Clicks desde Adwords: 3 - Strings de búsqueda encontrados: 1 FOTOS NOKIA 2720 (1) --------------------------------------------------------------------------------------------- Hay que tener cuidado de que "Google Search" no es sólo los dominios google.es/google.com/..., sinó también una red de afiliados de búsqueda (ejemplo, el buscador de Terra). En principio depende de varios factores: 1.- Que Google la "deje ver" en el Referer que nos ha enviado a nuestra web (normalmente en el parámetro "q=") 2.- Que la petición que ha llegado de Google o uno de sus asociados, vaya a una página donde esté activo el código de detección (el product, o una página de Shopping Engine) 3.- Que el código de detección esté funcionando bien (por ejemplo porque se haya cambiado la forma de enviar la KW, y ya no sea el parámetro "q=")	Solucionado! +Comentario
1671	03/11/2011 09:46:32	Benjamin Coll	Grave	Buenos días, otra vez han desaparecido datos del Panel de Control. En estas ocasión es para el día 22 de Octubre, lo he visto en este soporte (ZETANET) aunque es posible que esté sucediendo en otros. Hay que rascar a fondo este tema.	Solucionado! +Comentario
03/11/2011 09:47:23	Benjamin Coll	Este soporte (al igual que ZETANET, ver incidencia anterior) tampoco muestra datos de impresiones para el día 22 de Octubre. Se supone que el 6 de Octubre ya se solucionó esta incidencia para un problema similar que ocurrió en Septiembre con Orange y El Correo Gallego entre otros soportes. La resolución de esa incidencia fue la siguiente: "Solucionado!, por fin!. Era un bug difícil de encontrar el kabronazo. Lo que pasaba es que había un bug en sistema de carga de páginas vistas que se dejaba algunas inserciones por procesar junto con que el sistema no dejaba recachear datos de fechas anteriores. Ya lo he solucionado pero NO puedo recargar los datos del 11S porque mucho tiempo de proceso. Doy por solucionada la incidencia."
04/11/2011 17:15:03	Vicente Arteaga	Os comento que he encontrado un bug. No creo que afecte a esta incidencia, pero lo comento aquí por si afectara. Podría haber afectado a otras partes del sistema. No se me ocurre a priori cuales, ni he analizado en detalle a qué partes podría haber afectado, aunque donde seguro NO afecta es a Pelícano ni al sistema que decide qué versión de plantilla de AirSpeeder mostrar. El bug que he corregido estaba en la librería (lib-cbn.inc.php) que hace log de impresiones de FGs en los siguientes logs: /internet/VHs/share/datos/clicks2adserver/tracking_impresiones.YYYYMMDD.log /internet/VHs/share/datos/clicks2adserver/tracking_impresiones_dia.log Básicamente el fallo estaba en que hasta ahora en dichos logs nunca se guardaba el ID de plantilla de AirSpeeder. Siempre se guardaba un 0. Lo he corregido para que guarde el ID correcto, y así funcione correctamente la devolución de impresiones. Dichos logs se usan para cargar datos en las siguientes tablas: - estadisticas.hits2FGs_intradia - estadisticas.hits2FGs2pais - estadisticas.hits2FGs2comercio_dia - estadisticas.hits2FGs_stats Y acaba llegando también a la tabla: - estadisticas.hits2FGs
22/11/2011 21:30:43	Alex Ripoll	Todavía no he encontrado nada que me explique el problema. He procesado a mano todos los scripts y, para el día 22, si que obtengo impresiones para Zetanet pero no tantas como los días anteriores y posteriores.
14/12/2011 19:28:30	Alex Ripoll	El script principal que prepara los logs para la carga de impresiones lo hace de forma bastante compleja e incluye multiples conexiones de red para copiar ficheros mientras concatena procesos. Lo he en procesos mas pequeños y secuenciales para intentar aislar posibles problemas de red y que el código sea más legible. Esto no quiere decir que sea la solución pero nos dará más visibilidad. Lanzaré una carga de prueba para el día 3 con el distribuidor Salirpormadrid.com (ID=4024) que este día tuvo 0 impresiones.
1739	01/03/2012 10:25:17	Vicente Arteaga	Normal	Incidencia de Jedis de Productos en Blanco. Qué pude ver ayer: - Que los Jedis de Productos se mostraban en blanco, debido a que se devolvía la impresión. Aparentemente no encontraba Jedis de Producto por mostrar. No pude seguir investigando puesto que se solucionó el problema y no conseguí reproducirlo. - Que nos están haciendo peticiones manipulando las Cookies para intentar inyectar Javascript. La que seguro identifiqué fué la cookie USRUNI (ID de Usuario Único). Hay que analizar a qué puede afectar, y si realmente existe alguna vulnerabilidad. Este tipo de manipulaciones se siguen dando a día de hoy. - Muertes de php el día 29/2/2011 a las 10:30 am - 11:20 am. Podría deberse a alguna de los problemas de seguridad detectados en php 5.2.6. La versión 5.2.x ha dejado de estar soportada (ya no se actualizan con problemas de seguridad). Idealmente, habría que actualizarse a la 5.3.x última que haya. Si eso genera problemas, por lo menos actualizar a la 5.2.17 Dejo esto aquí por si se reproducen los problemas online.	Solucionado! +Comentario
1755	16/03/2012 09:01:31	Vicente Arteaga	Normal	Desde las 7:12 am de hoy 16/3/2011, ha vuelto a saltar otra alarma por pocos Creatives online, parando el CDC de control desconexiones. He modificado el sistema de alarmas, reduciendo el umbral de error (el tamaño del fichero binario de Creatives debía superar los 20KB, ahora debe superar los 12KB) para que el CDC de control desconexiones continúe trabajando. Benji, coméntalo con Sergio para que esté al tanto, y si es consciente de alguna falta de Creatives en algún comercio, que lo gestione. Una vez se implementen las tareas que permitirán aumentar la cantidad de creatives online, entiendo que ya no habrán estas incidencias.	Solucionado! +Comentario
1760	20/03/2012 10:43:58	Alex Ripoll	Normal	Se están generando un 5% de impresiones erróneas de productos (impresiones de los resultados de búsqueda en los SEs y XML) y hay que mirar porque está pasando. Estos datos erróneos se generan cuando: - No existe el ID de canal o tiene valor 0. - No existe el ID de comercio o tiene valor 0. - No existe el ID de producto único o tiene valor 0.	Solucionado! +Comentario
20/03/2012 14:28:35	Vicente Arteaga	Verificar que no es un tema de smith. Es algo que se está dando desde por lo menos el 1 de Enero del 2012, y que ha aumentado en % a partir de mediados de Febrero hasta casi un 10% de las impresiones.
1768	28/03/2012 10:29:09	Vicente Arteaga	Grave	BE9 ha generado un error SCSI. Es una de las tres máquinas que se usa a nivel de BBDD para los procesos de Backend de Jedis. Hay que: 1.- Analizar qué gravedad tiene el problema. 2.- Ver que se esté haciendo copia de seguridad de la información importante. 3.- Si es necesario en función del punto 1, ver cómo asegurar que está máquina esté al 100%, ya sea cambiando el disco por otro, o configurando una máquina nueva. El detalle del error es: Mar 28 10:10:44 cbbe9 kernel: SCSI error : return code = 0x8000002 Mar 28 10:10:44 cbbe9 kernel: Info fld=0x1318ffa5, Current sda: sense key Hardware Error Mar 28 10:10:44 cbbe9 kernel: Additional sense: Track following error Mar 28 10:10:44 cbbe9 kernel: end_request: I/O error, dev sda, sector 320405383 Mar 28 10:10:44 cbbe9 kernel: SCSI error : return code = 0x8000002 Mar 28 10:10:44 cbbe9 kernel: Info fld=0x1318ffaf, Current sda: sense key Hardware Error Mar 28 10:10:44 cbbe9 kernel: Additional sense: Track following error Mar 28 10:10:44 cbbe9 kernel: end_request: I/O error, dev sda, sector 320405423	Solucionado! +Comentario
28/03/2012 16:53:49	Vicente Arteaga	Si BE9 deja de funcionar afectaría al sistema de Jedis que prioriza Jedis y Sections por URL y al sistema que decide qué es mejor mostrar en una URL, si Jedis de Productos o Jedis de FGs. Qué hay que hacer, IMPORTANTE hacer hoy al menos el punto 1 y 2: 1.- Configurar el backup para que incluya todas las tablas que actualmente no están en backup, y forzar un backup. Tiempo Aprox: 30m Responsable: Alex o Vicente. 2.- Revisar el OMSA en BE9 y ya de paso BE15, y ver qué problemas hay reportados, si hay alguno. Instalar OMSA si es necesario. Tiempo Aprox: 30m Responsable: Alex o Vicente. 3.- Dentro del OMSA, específicamente, ver la tasa de fallos en los discos del RAID 1, y si hay alguno con demasiados fallos, reemplazarlo por uno de los que tenemos en la oficina. Tiempo Aprox: 15m - 1h Responsable: Alex o Vicente. Las tablas a incluir en backup son: BE9:foros.* BE9:oasis.url2crs_ctr (Se construye sólo cada día) BE9:oasis.url2crs_ctr_tmp (Se construye sólo cada día) BE9:oasis.url2crs_20YYMMDD (Al menos los últimos 9 días) BE9:oasis.TotalSiteStats_20YYMMDD (Al menos los últimos 9 días) BE15:oasis.usr2crs_20YYMMDD (Al menos los últimos 9 días) BE15:oasis.usr2topic2ctr_20YYMMDD (Al menos los últimos 9 días)
28/03/2012 19:08:15	Alex Ripoll	He hecho los puntos 1 y 2 pero el OMSA es imcompatible con la versión de SO que tenemos en BE9 y BE15 y no se puede instalar. He lanzado un report DSET, que es lo que nos suele pedir DELL para las incidencias, y hay que analizarlo para ver si nos da un poco más de visibilidad. En el backup he incluido las tablas especificadas en esta incidencia y se están guardando en el AX de BE13, en los directorios: /backup/BBDD/[YYYMMDD]/gatebe9/oasis /backup/BBDD/[YYYMMDD]/gatebe15/oasis
28/03/2012 20:29:51	Alex Ripoll	Segun el report del DSET, todos los discos están Status=OK y con Failure Predicted=NO. ¿?.
28/03/2012 23:59:03	Vicente Arteaga	Alex, Mírate que no haya nada sobre la controladora RAID. Si todo es OK, habría que: 4.- planificar la tarea que hablábamos esta tarde de hacer un backup de la estructura de BBDD (--no-data) de cada máquina, para poder recuperarla rápidamente. ¿2h? Responsable: Alex o Vicente 5.- establecer un protocolo de actuación en caso de fallo de BE9 (entiendo que sería aprox: parar procesos en BE7, recuperar de backup las tablas específicas de BE9 en ¿BE25?, renombrar "gatebe9" en todas las máquinas para que apunte a ¿BE25?, arrancar procesos en BE7).
30/03/2012 10:50:31	Alex Ripoll	No hay errores sobre la controladora RAID en el log generado por el DSET.
16/04/2012 12:18:13	Benjamin Coll	Está funcionando todo bien: si funciona, no lo tocamos hasta nueva orden.
1784	14/05/2012 11:04:19	Vicente Arteaga	Normal	Una máquina que NO está en producción ha reportado un error en un disco. La máquina es bebd1 (NO confundir con bebbdd1). Los mensajes reportados son: omsa error : 2051 Physical disk degraded: Physical Disk 1:2 Controller 0, Connector 1 omsa error : 2094 Predictive Failure reported: Physical Disk 1:2 Controller 0, Connector 1 syslog looks fine no Siguientes pasos: En la siguiente ocasión que se vaya a Colt, llevarse un disco para substituir el disco en fallo. Considero que NO merece la pena ir sólo para cambiar este disco porque: - En caso de fallar el otro disco del RAID1, sólo se vería afectada una de las particiones de datos de BBDD, y NO requeriría reinstalar la maquina. - Es una máquina que no está en producción.	Solucionado! +Comentario
15/05/2012 11:42:13	Benjamin Coll	La máquina no está dando servicio, la dejamos así hasta nueva orden.
1796	22/05/2012 17:08:51	Vicente Arteaga	Normal	La máquina BEBD2 (NO confundir con BEBBDD2), que es una máquina poco crítica, estaba comportándose de forma extraña. La he reiniciado, y NO arranca. He pedido un remote hands para reiniciarla: Ticket #1747252	Solucionado! +Comentario
22/05/2012 17:27:43	Vicente Arteaga	Vía remote hands me confirman que la máquina SI está arrancada. Aparentemente el problema es que no ha configurado correctamente la red. La única forma de solventarlo es desplazándose hasta Colt. Alternativamente, nos olvidamos de esta máquina hasta que tengamos que ir a Colt por cualquier otro motivo, y se configura correctamente.
22/05/2012 22:32:25	Alex Ripoll	He ido a COLT y el servidor estaba encendido pero en modo 'read only filesystem' debido a que no encontraba la definición del 'super block' del sistema de ficheros de la partición /dev/sda He dejado lanzado el comando para reconstruir el sistema de ficheros (fsck.resiserfs --rebuild-tree) pero tardará muchísimo ya que en 30 minutos todavía no había llegado al 1%. (Adjunto pantallazo). No pinta nada bien pero el jueves volveré a pasar por COLT y a ver si tenemos suerte y podemos recuperarlo. IMG_20120522_193445.jpg
24/05/2012 16:16:39	Alex Ripoll	No he conseguido recuperarla y sigue dando los mismos errores, no detecta discos del PV, da muchos errores SCSI... He probado desconectando el PV, cambiando cables y nada. La he dejado encendida con acceso por red por si podemos llegar a diagnosticar algo desde la ofi. Mi propuesta es reinstalarla desde cero con una versión de SuSE más moderna y reutilizar el nuevo servidor para otros proyectos o para la mismo que estaba haciendo. Reinstalar desde cero me supone unas 2h de trabajo.
1862	22/11/2012 16:57:04	Sergio Lopez	Normal	TCS FG's: El Anunciante Latiendadelosperfumes [22178] contrató una campaña de FGs a CPM del 4 al 25 al Julio. Desde entonces, Watto king ha registrado 4 ventas provenientes de esta campaña con las siguientes fechas: 24/7, 20/08, 2/11 y 14/11. Los pedidos registrados en el mes de Noviembre realizados en Prensa Escrita y Libertad Digital NO deberían aparecer ya que en principio se han superado los 30 días de la fecha fin de la campaña de FG's. Si se trabajo una campaña en Octubre de PRD a CPC. En la integración del TCS de la intranet aparece como "días de seguimiento de la cookie del TCS" a 30 días.	Solucionado! +Comentario
1869	15/01/2013 12:46:50	Sergio Lopez	Normal	Retargeting La tienda Home: Alvaro me comenta que solo visualiza el jedi genérico de la Tienda Home. Adjunto imagen.	Solucionado! +Comentario
15/01/2013 12:46:50	Sergio Lopez	Se ha adjuntado un fichero Jedi_LTH.jpg
15/01/2013 13:18:24	Alex Ripoll	Los Jedis genéricos RTT aparecen cuando el ad_tpl detecta la cookie de usuario pero ve que este usuario NO tienen productos asociados de LaTiendaHome. Es decir, es como si el usuario hubiera visitado la portada de LaTiendaHome y, como no coincide con ningún producto del PCS, pues el ad_tpl le muestra el genérico. En mi caso si que me está mostrando productos relacionados (adjunto pantallazo) y, para saber con más detalle si se trata de un error, necesito saber cual es la cookie de usuario de Alvaro. Ahora se la ido y sigo analizando. RTT_1117_home.jpg
1870	16/01/2013 09:38:34	Vicente Arteaga	Normal	Esto no es crítico actualmente, pero habrá que tenerlo analizado por si suben las impresiones NO remuneradas. Hay que ganar visibilidad en cuanto costaría optimizar el rendimiento de la carga de impresiones de FGs: La carga de impresiones de FGs se ralentiza bastante, y se ralentiza mucho si hay un tráfico un poco más elevado, o bloqueos (por ejemplo de madrugada mientras se ejecutan los procesos nocturnos). En los momentos de madrugada, cuando han pasado los bloqueos, se baja a una ejecución cada 20 minutos aprox. Y lo habitual es que durante el día sea cada 35 minutos aprox. Pero durante la tarde va aumentando hasta 2h por ejecución, y eso no da mucha granularidad a la hora de ver campañas si han finalizado, desconectar campañas por llegar a Ppto diario, ...	Solucionado! +Comentario
1873	28/01/2013 09:23:51	Alex Ripoll	Normal	El PHP de BE10 vtriggerClaves2Productos.php ha generado el siguiente error: cbbe10 kernel: vtriggerClaves2[12808]: segfault at 00000000ffff3f60 rip 0000000008396a13 rsp 00000000ffff3f60 error 6 Hay que analizar a que es debido y posibles colaterales (si hay).	Solucionado! +Comentario
11/02/2013 17:31:39	Alex Ripoll	Este error no generó ningún colateral y, analizando el código, lo que veo es que puede que fuera por un error temporal por consumo de memoria RAM. No ha vuelto a suceder desde el pasado día 28 y dejo la incidencia activa para hacer seguimiento.
1874	28/01/2013 10:27:49	Vicente Arteaga	Normal	Es espacio en disco de BE17 está al 90% de uso. Va subiendo lentamente pero continuadamente. Analizar y si es necesario, desglosar en tareas para que se limpie, a ser posible automáticamente.	Solucionado! +Comentario
28/01/2013 10:35:28	Vicente Arteaga	Se ha adjuntado un fichero. procallator_cbbe17_gauge_volatile_mnt_(._X_)-yearly.png
04/02/2013 11:51:55	Alex Ripoll	El problema son las siguientes tablas de BD que ocupan más del 50% del disco: 12GBs => oasis.url2site2notclassified 15GBs => oasis.url2site 16GBs => oasis.url2site2pending 17GBs => oasis.url2site2pendingTmp Pero ninguna de ellas tiene el campo fecha para poder facer un borrado y optimización de datos. Necesito que Vicente dedique un tiempo a explicarme a que procesos corresponden estas tablas, que hacen, si hay alguna que se pueda borrar sin afectar a los Jedis online y, a partir de ahí, habrá que desglosar desarrollos en tareas para hacer que estas tablas tengan fecha y podamos incluirlas dentro del proceso semanal de borrado y optimización.
1880	10/02/2013 19:38:13	Vicente Arteaga	Normal	Aparentemente ha fallado la RAM de la controladora RAID de BO1 (BE2). Con un poco de suerte sólo afecta en el caso de un apagado por falta de electricidad. Hay que estar atento por si causa una caida en el rendimiento de BO1 (BE2): Feb 9 16:02:05 cb-bo1 kernel: aacraid:ID(0:00:0); Error Event [command:0x28] Feb 9 16:02:05 cb-bo1 kernel: aacraid:ID(0:00:0); Hardware Error [k:0x4,c:0x40,q:0x8c] Feb 9 16:02:05 cb-bo1 kernel: aacraid:ID(0:00:0); RAM Failure	Solucionado! +Comentario
10/02/2013 19:55:18	Vicente Arteaga	La siguiente vez que se vaya a Colt, verificar los discos de BO1 (BE2), ya que estos mensajes dan a entender que un disco está dando problemas: Feb 9 04:30:14 cb-bo1 kernel: aacraid:ID(0:00:0); Error Event [command:0x28] Feb 9 04:30:14 cb-bo1 kernel: aacraid:ID(0:00:0); Medium Error [k:0x3,c:0x11,q:0x0] Feb 9 04:30:14 cb-bo1 kernel: aacraid:ID(0:00:0); Unrecovered Read Error Feb 9 04:30:16 cb-bo1 kernel: aacraid:ID(0:00:0) Medium Error, LBN Range 80215938:80216065 Feb 9 04:30:17 cb-bo1 kernel: aacraid:ID(0:00:0) Starting BBR sequence
13/02/2013 10:53:37	Alex Ripoll	He verificado los discos en COLT y todas las luces en verde, como si no hubiera ningún problema. Seguimos monitorizando por si acaso.
1881	14/02/2013 13:13:09	Sergio Lopez	Grave	Retargeting Latiendahome [ID=1117] Alvaro comenta lo siguiente: Desde el dia 22 de enero la campaña ha registrado únicamente 3 clicks ( 1 click día 31/01/12 y 2 clicks el 07/02/12). He revisado que los jedis de retargeting aparezcan online y linken correctamente y todo parece Ok. Revisar por favor si todo funciona correctamente y si hay algún motivo que pueda explicar este volumen tan bajo de clicks.	Solucionado! +Comentario
20/02/2013 11:36:43	Sergio Lopez	Hemos modificado el CPC a 0,42€ y no han mejorado los resultados. Necesitamos saber que podemos hacer para generar mayor volumen de clicks.
20/02/2013 11:52:56	Alex Ripoll	Técnicamente los procesos también están funcionando bien. Tal como lo veo, para generar más clicks quedan las siguientes opciones: 1) Tocar las frecuencias para que tenga más visibilidad 2) Hablar con Vicente para que nos recuerde la lógica que sigue el ad_tpl para mostrar anuncios RTT. Creo recordar que era muy conservadora y se podía hacer que fuera un poco más agresiva.
1885	19/03/2013 15:38:03	Vicente Arteaga	Normal	La ADSL de Comerciales ha dejado de funcionar. He abierto incidencia sobre el número asociado (932059689) y nos tienen que dar solución en menos de 12h. Mientras tanto he hecho que usemos la ADSL de técnicos. Alex, FYI, he cambiado la IP del router de comerciales de la 192.168.10.252 a la 192.168.10.202, y he añadido al servidor cbbdlocal (192.168.10.226) la IP 192.168.10.252 y he configurado a cbbdlocal para que haga NAT a la IP 192.168.1.253.	Solucionado! +Comentario
19/03/2013 19:17:17	Vicente Arteaga	Ya han solucionado el problema con la ADSL de Comerciales. Mañana por la mañana pondré la ADSL de Comerciales en producción.
21/03/2013 14:22:15	Vicente Arteaga	Ya he puesto la ADSL de Comerciales en producción. Se puede cerrar esta incidencia.
1886	19/03/2013 17:29:38	Sergio Lopez	Armageddon	Se estan generando clicks remunerados a productos inactivos a través de una IP USA que proceden aparentemente de Adwords. El comercio al que se le detecto este problema es Latiendadelosperfumes (ID=22178). Id de Producto ejemplo: 173974021 Detectar a que se debe el problema, de momento borraré todos los clicks de los productos afectados con lo cual es importante que se solucione lo antes posible.	Solucionado! +Comentario
19/03/2013 19:16:19	Vicente Arteaga	No me voy a encargar del análisis, pero os comento lo siguiente FYI: Ojo que por defecto las campañas de Adwords NO incluyen ninguna restricción de país, sinó que se muestran en los portales del idioma especificado. Hay que incluir EXPLICITAMENTE la restricción de País.
1887	22/03/2013 11:31:31	Sergio Lopez	Normal	Incidencia de Prepago: Karina comenta: "Necesito analizar que ocurre en la cantidad de Limite Clicks Productos en el momento de ejecutar el prepago de forma manual desde la ficha del Anunciantes Tienda Siglo XXI, ID. 21356. De acuerdo con el email que se ejecuta de forma automatica al momento de procesar el Prepago, y tanto en la ficha en el punto Registro Modificaciones Ficha, se observa que la cantidad limite de click es de 8.260, Cuando en realidad deberia ser 2.480 Clicks. (Te adjunto copia del email recibido) https://intranet.codigobarras.com/incidencias_comercio.php?id_comercio=21356\|Tienda+Siglo+XXI Si, en las Condiciones AD.Online, se visualiza correctamente la cantidad de clicks a consumir de 2.480. Solicito corregir el fallo, para evitar cualquier tipo de incidencia relacionada con la campaña."	Solucionado! +Comentario

Total Incidencias: 32