6/11/21

GA4: Cómo asignar user_id a la primera visita de un usuario no logueado (Web)


Antes de comenzar, debes cumplir con los siguientes requisitos:

  1. Uno o más flujos Web capturando datos para la misma propiedad de GA4. 
  2. Variable de user_id configurada en GA4 para usuarios que inician sesión. 
  3. Enlace de la propiedad de GA4 con Bigquery. 
  4. Bigqury activado (recuerda que usar BQ no es gratuito).
Si cumples con estos requisitos, puedes hacer muchas cosas que no se pueden lograr solo con los reportes. 

Con el siguiente ejemplo, puedes recuperar todos los user_pseudo_id (Client ID) asignados al evento first_visit, que corresponde al primer ingreso de un usuario al sitio Web y que no tiene un user_id asignado; y si el usuario se registra y se le asigna un user_id, puedes hacer match con su user_pseudo_id para conocer el user_id retroactivamente.

SELECT
    client_id, user_id,
    first_visit, device
FROM (
    SELECT
        primera.user_pseudo_id as client_id, 
        segunda.user_id as user_id,
        primera.event_date AS first_visit,
        primera.device.category as device, 
        ROW_NUMBER() OVER(PARTITION BY primera.user_pseudo_id ORDER BY primera.event_timestamp DESC) AS row_num
    FROM `********.events_*` as primera
    JOIN (SELECT user_id, user_pseudo_id 
      FROM `********.events_*`
      WHERE _TABLE_SUFFIX BETWEEN '20210601' AND '20211031'
      AND user_id IS NOT NULL
      GROUP BY user_id, user_pseudo_id) as segunda
    ON primera.user_pseudo_id = segunda.user_pseudo_id
    WHERE event_name="first_visit"
    AND _TABLE_SUFFIX BETWEEN '20210601' AND '20211031')
WHERE row_num=1


No olvides editar el origen de los datos y las fechas.  En este ejemplo el origen de los datos es el mismo en ambos "FROM".

Comenta si te funcionó. Si tienes otras soluciones para compartir o hay algún dato que no puedes rescatar, también comenta 💝

15/8/20

Cache simple para posts en Wordpress


Una serie de problemas con los plugins de cache de Wordpress me llevaron a buscar una alternativa. Y encontré una bastante simple.

Dos archivos php extra dentro del theme. Una carpeta para guardar las páginas cacheadas. Y una edición al archivo single.php

Primero, dos archivos nuevos:

top-cache.php

<?php
$url = $_SERVER["SERVER_NAME"].str_replace("/", "-", strtok($_SERVER["REQUEST_URI"], '?'));
$cachefile = './wp-content/cache/cached-'.$url.'.html';
// lee del cache si el archivo es posterior a la última modificación del post
if (file_exists($cachefile) && get_post_modified_time( 'U', false, $post->ID, true ) < strtotime('-4 hours', filemtime($cachefile))) {
readfile($cachefile);
exit;
}
ob_start();

La variable $cachefile define la ruta de la carpeta donde se guardan las páginas cacheadas.

La variable $url construye el nombre del archivo que se guardará en el cache. Incluye el hostname y la ruta de la página sin las query (para prevenir que se guarden en cache páginas con variables UTM u otras).

La ruta para guardar los archivos del cache en este caso es /wp-content/cache/ . Si la carpeta /cache/ no está creada, tienes que crearla con el FTP. Con permisos chmod 0775.

Si la fecha de modificación del post es anterior a la fecha de creación del archivo en cache, lee el cache. En caso contrario, ejecuta el resto del código (el de la página single.php), incluido el segundo archivo nuevo:

bottom-cache.php

<?php
$url = $_SERVER["SERVER_NAME"].str_replace("/", "-", strtok($_SERVER["REQUEST_URI"], '?'));
$cachefile = './wp-content/cache/cached-'.$url.'.html';
$cached = fopen($cachefile, 'w');
fwrite($cached, ob_get_contents());
fclose($cached);
ob_end_flush(); // Send the output to the browser

Este documento repite las variables $url y $cachefile. Y crea el archivo dentro de la carpeta cache.

Cuando la página está en cache, este archivo no se ejecuta.

single.php

En la página single.php hay que hacer dos pequeñas modificaciones. 

Al comienzo del archivo:

<?php
if (!is_user_logged_in()) {
  include('top-cache.php');
}
get_header(); ?>

Y al final del archivo:

<?php
get_footer();
if (!is_user_logged_in()) {
  include('bottom-cache.php');
}

Si el visitante NO está logueado, entonces carga top-cache.php y bottom-cache.php. Esto previene que los editores y administradores de Wordpress vean páginas cacheadas.

Espero que les sirva. 

19/7/20

Hard Refresh de una página con problemas de cache



Todavía no sé por qué ocurre. Podría ser el theme, la configuración del htaccess o del wp-config. Pero mi sitio Web wordpress no actualiza las URL si no refresco la página. 

Navegaba por todas las URL del sitio y todas mostraban el mismo contenido, de la última URL. Solo al presionar F5 lograba ver el contenido correcto.

Probé con todo lo que sé. Busqué en todas partes y obtuve alguna información. Es el cache del sitio. Pero no sé más que eso. Y ante tanta frustración, prefería hacer un parche absurdo, que funciona.

Cuando el Path del post en la URL no coincide con el Path del post que se carga en la página, hace un Hard Refresh. 

<script type="text/javascript">
  if (window.location.pathname !== "<?php if (!is_singular()) {
    echo strtok($_SERVER["REQUEST_URI"], '?');
  } else {
    echo str_replace(home_url(), '', get_permalink($post->ID));
  } ?>"){
    location.reload(true);
  }
</script>

Esta solución de parche recarga la página si el Path del post en el código no coincide con el Path del post en la URL.

UPDATE


Luego de hacer pruebas por largas horas, agregando y quitando elementos del htaccess, legué a una extraña revelación: las reglas de caché y deflate para las páginas son las que fuerzan la carga de una página que no corresponde. Al menos éste fue mi caso.

Si te ocurre lo mismo, ve al htaccess y comenta las reglas de caché y deflate para estos tres tipos de documento:

  • text/html
  • text/xml
  • text/x-component

;)