Je possède une startup auto-financée. En tant que tel, je veux obtenir tout ce que je peux gratuitement avant de convaincre notre directeur financier de dépenser nos fonds de démarrage gagnés avec un tel effort. Je suis aussi un analyste avec une expérience en informatique et en données, donc un peu geek, quelle que soit sa définition.
Ce que j'essaie de faire, avec mon chapeau d’analyste en référencement, est de rechercher d’excellentes sources de données gratuites et d’en discuter de manière éclairante. Parce que? Parce qu'il est inutile de baser les conseils du client sur des devinettes. Il est bien préférable de combiner des données de qualité avec une bonne analyse et d’aider nos clients à mieux comprendre les domaines sur lesquels ils doivent se concentrer.
Dans cet article, je vais vous expliquer comment commencer à utiliser certaines ressources gratuites et à illustrer comment rassembler des analyses uniques fournissant des informations utiles pour les articles de votre blog si vous êtes un écrivain, votre agence s'il s'agit d'un référencement ou de votre site Web. Si vous êtes un client ou un propriétaire qui fait du référencement vous-même.
Le scénario que je vais utiliser est que je souhaite analyser certains attributs de référencement (par exemple, les liens retour, l'autorité de page, etc.) et analyser leur effet sur le classement Google. Je veux répondre à des questions telles que "Les backlinks sont-ils vraiment importants pour accéder à la page 1 des SERPs?" Et "Quel type de score d'Autorité de la page dois-je vraiment être dans le top 10 des résultats?" Pour ce faire, je devrai combiner les données d'une série de recherches Google avec des données sur chaque résultat possédant les attributs de référencement que je souhaite mesurer.
Commençons par analyser comment combiner les tâches suivantes, qui peuvent être configurées gratuitement:
- Consultez le moteur de recherche personnalisé de Google
- Utilisation du compte API gratuit de Moz
- Collection Vérification des données avec PHP et MySQL
- Analyse des données avec SQL et R
Vérifiez avec le moteur de recherche personnalisé de Google
Nous devons d'abord vérifier les résultats de Google et les stocker. Pour rester dans la partie droite des conditions d'utilisation de Google, nous n'allons pas supprimer Google.com directement, mais nous utiliserons la fonctionnalité de recherche personnalisée de Google. La recherche personnalisée Google est principalement conçue pour permettre aux propriétaires de sites Web de fournir un widget de recherche similaire à Google sur leur site Web. Cependant, il existe également une API de recherche Google basée sur REST qui est gratuite et vous permet d'interroger Google et de récupérer les résultats au format JSON très répandu. Il existe des limites de quota, mais elles peuvent être configurées et étendues pour fournir un bon échantillon de données à utiliser.
Lorsqu'il est configuré correctement pour effectuer des recherches sur l'ensemble du Web, vous pouvez envoyer des requêtes à votre moteur de recherche personnalisé, dans notre cas avec PHP, et les traiter comme des réponses de Google, avec toutefois quelques avertissements. Les principales limitations de l'utilisation d'un moteur de recherche personnalisé sont les suivantes: (i) il n'utilise pas certaines fonctionnalités de Google Web Search, telles que les résultats personnalisés et; (ii) Vous pouvez avoir un sous-ensemble de résultats d'index de Google s'il inclut plus de dix sites.
Malgré ces limitations, de nombreuses options de recherche peuvent être transmises au moteur de recherche personnalisé afin de représenter les résultats attendus de Google.com. Dans notre scénario, nous passons ce qui suit lors d'un appel:
https://www.googleapis.com/customsearch/v1?key=& userIp = & cx & q = iPhone + X & cr = countryUS & start =
1
Où:
- https://www.googleapis.com/customsearch/v1 – correspond à l'URL de la clé de l'API de recherche personnalisée Google
- =
– Votre clé d'API Développeur Google - userIp =
– L'adresse IP de la machine locale effectuant l'appel - cx =
– Votre identifiant de moteur de recherche personnalisé Google - q = iPhone + X – La chaîne de requête Google (& # 39; + & # 39; remplace & # 39; & # 39;)
- cr = countryUS – Restriction de pays (à partir de la liste des noms de collection de pays Goolge) [19659007] start = 1 – Index du premier résultat renvoyé, p. Par exemple, la page 1 de la SERP. Les appels successifs augmenteraient le nombre de pages 2 à 5.
Google a déclaré que le moteur de recherche personnalisé de Google était différent de celui de Google .com, mais dans mon test de produit limité comparant les résultats. entre les deux, il m'a encouragé les similitudes et il a donc poursuivi l'analyse. Cela dit, n'oubliez pas que les données et les résultats ci-dessous proviennent de la recherche personnalisée Google (en utilisant des requêtes "sur le Web entier") et non de Google.com.
Utilisation du compte API gratuit de Moz
Moz fournit une interface de programmation d'application (API). Pour l'utiliser, vous devez vous enregistrer pour obtenir une clé de l'API Mozscape, gratuite mais limitée à 2 500 lignes par mois et une requête toutes les dix secondes. Les plans actuellement payés vous donnent des frais plus élevés et commencent à 250 $ par mois. En ayant un compte gratuit et une clé API, vous pouvez interroger l'API de lien et analyser les métriques suivantes:
|
Champ de données Moz |
Code de l'API Moz |
Description |
|---|---|---|
|
ueid |
32 |
Le nombre de liens d'équité externes vers l'URL |
|
uid |
2048 |
Le nombre de liens (externes, équitables ou non équitables) vers l'URL |
|
umrp ** |
16384 [19659030] Le MozRank de l’URL, score standardisé de 10 points |
|
|
umrr ** |
16384 |
Le MozRank de l’URL, sous forme de score non traité |
|
fmrp ** |
32768 [19659030] Le MozRank du sous-domaine URL, sous forme de score normalisé de 10 points |
|
|
fmrr ** |
32768 |
Le MozRank du sous-domaine URL, sous forme de score non traité |
|
us |
536870912 |
Code de statut HTTP enregistré pour cette URL, s'il est disponible |
|
. Upa [19659030] 34359738368 |
Score normalisé de 100 points représentant la probabilité qu’une page soit bien classée dans les résultats de moteur de recherche |
|
|
pda [19659030] 68719476736 |
Un score normalisé de 100 points représentant la probabilité qu'un domaine est bien classé dans les résultats des moteurs de recherche |
REMARQUE: Cette analyse étant capturée, Moz a indiqué qu'il avait désapprouvé ces champs. Cependant, lors de l’essai (06-15-2019), les champs étaient toujours présents.
Les codes de l'API de Moz sont ajoutés avant d'appeler l'API de liens avec un nom similaire à celui-ci:
www.apple.com% 2F? Cols = 103616137253 & AccessID = MOZ_ACCESS_ID &
Expires = 1560586149 & Signature =
Où:
- http://lsapi.seomoz.com/linkscape/url-metrics/ "class =" editor-autoparser-object "> http://lsapi.seomoz.com / linksc … – C'est l'URL de l'API Moz
- http% 3A% 2F% 2Fwww.apple.com% 2F – Une URL cryptée à partir de laquelle nous voulons obtenir des données
- Cols = 103616137253 – La somme de Codes d'API Moz de la table précédente
- AccessID = MOZ_ACCESS_ID – Version chiffrée de l'ID d'accès Moz (figurant dans votre compte API)
- Expires = 1560586149 – Délai d'attente pour la requête – en définir une minutes in the future [19659007] Signature =
– Une version chiffrée de l'ID d'accès Moz (figurant dans votre compte API)
Moz renverra avec quelque chose comme le JSON suivant:
Matrix
(
[ut] => Apple
[uu] => www.apple.com/
[ueid] => 13078035
[uid] => 14632963
[uu] => www.apple.com/
[ueid] => 13078035
[uid] => 14632963
[umrp] => 9
[umrr] => 0.8999999762
[fmrp] => 2.602215052
[fmrr] => 0.2602215111
[us] => 200
[upa] => 90
[pda] => 100
)
Pour un excellent point de départ pour consulter Moz avec PHP, Perl, Python, Ruby et Javascript, consultez ce dépôt sur Github. J'ai choisi d'utiliser PHP.
Collecte de données avec PHP et MySQL
Maintenant que nous avons un moteur de recherche Google personnalisé et notre API Moz, nous sommes presque prêts à capturer des données. Google et Moz répondent aux demandes via le format JSON, ce qui leur permet d'être consultés par de nombreux langages de programmation courants. En plus de la langue que j'ai choisie, PHP, j'ai écrit les résultats de Google et de Moz dans une base de données et j'ai choisi MySQL Community Edition pour cela. D'autres bases de données pourraient également être utilisées, par exemple Postgres, Oracle, Microsoft SQL Server, etc. Cela permet la persistance des données et une analyse ad-hoc en utilisant SQL (Structured Query Language) et d'autres langages (tels que R, que j'analyserai plus tard). Après avoir créé des tables de base de données contenant les résultats de recherche Google (avec des champs pour plage, URL, etc.) et une table contenant des champs de données Moz (ueid, upa, uda, etc.), nous sommes prêts pour concevoir notre plan de collecte de données. [19659002] Google propose des frais généreux avec le moteur de recherche personnalisé (jusqu'à 100 millions de requêtes par jour avec la même clé de la console pour développeurs Google), mais l'API gratuite de Moz est limitée à 2 500. Bien que pour Moz, les options payantes fournissent entre 120 000 et 40 millions de lignes par mois, selon les plans et le coût varie entre 250 et 10 000 dollars par mois. Par conséquent, comme je n’explore que l’option gratuite, j’ai conçu mon code pour collecter 125 requêtes Google sur 2 pages de SERP (10 résultats par page), ce qui me permet de respecter le quota de 2 500 lignes de Moz. En ce qui concerne les recherches à faire sur Google, il existe de nombreuses ressources à utiliser. J'ai choisi d'utiliser Mondovo car ils fournissent de nombreuses listes par catégorie et jusqu'à 500 mots par liste, ce qui est suffisant pour l'expérience.
J'ai également inclus des classes d'aide PHP avec mon propre code pour la base de données et HTTP I / O.
En résumé, les principaux blocs de construction et sources PHP utilisés étaient les suivants:
Un facteur à prendre en compte est l'intervalle de 10 secondes entre les appels d'API Moz. Ceci afin d'éviter que Moz ne soit surchargé par les utilisateurs d'API libres. Pour gérer cela dans le logiciel, j'ai écrit un "régulateur de requête" qui bloquait l'accès à l'API de Moz entre les appels successifs sur une période donnée. Cependant, bien que cela fonctionne parfaitement, cela signifiait qu'il suffisait de moins de 7 heures pour appeler Moz 2500 fois de suite.
Analyse des données avec SQL et R
Données collectées. Maintenant, le plaisir commence!
Il est temps d'examiner ce que nous avons. Ceci est parfois appelé conflit de données. J'utilise un langage de programmation statistique gratuit appelé R avec un environnement de développement (éditeur) appelé R Studio. Il existe d'autres langages tels que Stata et d'autres outils de science des données graphiques tels que Tableau, mais ces coûts et le directeur financier de Purple Toolz ne font pas l'unanimité.
J'utilise R depuis plusieurs années, car il est open source et possède de nombreuses bibliothèques tierces, ce qui le rend extrêmement polyvalent et approprié pour ce type de travail.
Retroussons nos manches.
J'ai maintenant quelques tables de base de données avec les résultats de mes requêtes de 125 termes de recherche sur 2 pages SERPS (c'est-à-dire, 20 URL triées par terme de recherche). Deux tables de la base de données contiennent les résultats de Google et une autre table contient les résultats des données de Moz. Pour y accéder, nous devons créer une base de données INNER JOIN facile à utiliser avec le paquetage RMySQL avec R. Celle-ci est chargée en tapant "install.packages (& # 39; RMySQL & # 39;)" dans la console R et en incluant la ligne "library (RMySQL)" en haut de notre script R.
Nous pouvons ensuite procéder comme suit pour vous connecter et obtenir les données dans une variable de cadre de données R appelée "theResults".
bibliothèque (RMySQL)
# INTERIOR JOIN les deux tables
theQuery <- "
SÉLECTIONNER A. *, B. *, C. *
De
(
SELECT
cseq_search_id
DE cse_query
) A - Requête de recherche personnalisée
REJOIGNEZ INTERNE
(
SELECT
cser_cseq_id,
cser_rank,
cser_url
DE cse_results
) B - Résultats de recherche personnalisés
ON A.cseq_search_id = B.cser_cseq_id
REJOIGNEZ INTERNE
(
SELECT *
De moz
) C - Champs de données Moz
IN B.cser_url = C.moz_url
;
"
# [1] Connectez-vous à la base de données
# Remplacez USER_NAME par votre nom d'utilisateur de base de données
# Remplacez PASSWORD par votre mot de passe de base de données
# Remplacez MY_DB par le nom de votre base de données
theConn <- dbConnect (dbDriver ("MySQL"), utilisateur = "USER_NAME", mot de passe = "PASSWORD", dbname = "MY_DB")
# [2] Consultez la base de données et conservez les résultats.
theResults <- dbGetQuery (theConn, theQuery)
# [3] Déconnecter de la base de données
dbDisconnect (theConn)
REMARQUE: J'ai deux tables pour enregistrer les données de moteur de recherche Google. L'un contient des données sur la requête Google (cse_query) et l'autre des résultats (cse_results).
Nous pouvons maintenant utiliser toute la gamme des fonctions statistiques de R pour commencer à discuter.
Commençons par quelques résumés pour avoir une idée des données. Le processus que je suis en train de suivre est fondamentalement le même pour chacun des champs. Nous allons donc illustrer et utiliser le champ "UEID" de Moz (le nombre de liens d'équité externes à une URL). En écrivant ce qui suit dans R je reçois ceci:
> summary (theResults $ moz_ueid)
Min 1ère Qu. Moyenne Moyenne 3ème Qu. Max.
0 1 20 14709 182 2755274
> quantile (theResults $ moz_ueid, probs = c (1, 5, 10, 25, 50, 75, 80, 90, 95, 99, 100) / 100)
1% 5% 10% 25% 50% 75% 80% 90% 95% 99% 100%
0.0 0.0 0.0 1.0 20.0 182.0 337.2 1715.2 7873.4 412283.4 2755274.0
En regardant cela, vous pouvez voir que les données sont biaisées (beaucoup) par le rapport de la médiane à la moyenne, qui est extrait par les valeurs du quartile supérieur ( valeurs supérieures à 75% des observations). Toutefois, nous pouvons tracer ce diagramme sous forme de diagramme en forme de boîte et de moustache dans R, où chaque valeur X correspond à la distribution des UEID par rang à partir de la position de recherche personnalisée Google 1-20.
Notez que nous utilisons une échelle logarithmique sur l'axe et que nous pouvons afficher la plage complète des valeurs, car elles varient considérablement.
Les diagrammes de boîtes et de moustaches sont excellents, car ils contiennent beaucoup d'informations (voir la fonction geom_boxplot dans R). La zone en violet représente la gamme inter-quartile (IQR), qui correspond aux valeurs comprises entre 25% et 75% des observations. La ligne horizontale dans chaque "case" représente la valeur moyenne (celle du milieu lorsque celle-ci est commandée), tandis que les lignes qui sortent de la case (appelées "moustaches") représentent 1,5 x IQR. Les points situés en dehors des moustaches sont appelés "points aberrants" et indiquent où se trouvent les extensions de l'ensemble d'observations de chaque plage. Malgré l’échelle logarithmique, on note une progression notable des valeurs moyennes du rang 10 au rang 1, ce qui indique que le nombre de liens d’équité pourrait être un facteur de classement de Google. Explorons cela davantage avec les tableaux de densité.
Les graphiques de densité ressemblent beaucoup aux distributions (histogrammes) mais montrent des lignes lisses au lieu de barres pour les données. A l'instar d'un histogramme, le pic d'un graphique de densité indique l'endroit où les valeurs de données sont concentrées et peut aider en comparant deux distributions. Dans le graphique de densité ci-dessous, j'ai divisé les données en deux catégories: (i) les résultats apparaissant à la page 1 des SERP notés 1-10 sont en rose et; (ii) les résultats apparaissant dans SERP sont en bleu. J'ai également dessiné les médianes des deux distributions pour illustrer la différence de résultats entre la page 1 et la page 2.
L'inférence de ces deux graphes de densité est que les résultats du SERP à la page 1 avaient davantage de liens. Recul d'équité externe (UEID) au lieu des résultats. Vous pouvez également voir les valeurs moyennes pour ces deux catégories ci-dessous, qui montrent clairement que la valeur de la page 1 (38) est beaucoup plus grande que celle de la page 2 (11). Nous avons donc maintenant quelques chiffres sur lesquels baser notre stratégie de référencement des backlinks.
# Crée un facteur dans R selon la page SERP où un résultat est trouvé (cser_rank)
> theResults $ rankBin <- paste("Page", ceiling(theResults$cser_rank / 10))
> theResults $ rankBin <- factor(theResults$rankBin)
# Now report the medians by SERP page by calling ‘tapply’
> peu à peu (theResults $ moz_ueid, theResults $ rankBin, moyen)
Page 1 Page 2
38 11
Nous pouvons en déduire que les backlinks sur actions (UEID) sont importants et si je conseillais un client sur la base de ces données, je dirais qu'il devrait chercher à dépasser 38 backlinks basés sur des actions pour les aider à atteindre une page 1 des SERPs. Bien sûr, il s'agit d'un échantillon limité et davantage de recherche, d'un échantillon plus grand et d'autres facteurs de classification doivent être pris en compte, mais l'idée est bien comprise.
Examinons maintenant une autre mesure moins étendue que l'UEID et examinons la mesure UPA de Moz, qui correspond à la probabilité qu'une page se classe bien dans les résultats de moteur de recherche.
> résumé (theResults $ moz_upa)
Min 1ère Qu. Moyenne Moyenne 3ème Qu. Max.
1,00 33,00 41,00 41,22 50,00 81,00
> quantile (theResults $ moz_upa, probs = c (1, 5, 10, 25, 50, 75, 80, 90, 95, 99, 100) / 100)
1% 5% 10% 25% 50% 75% 80% 90% 95% 99% 100%
12 1965 2567 41 50 53 58 62 75 81
L'UPA est un nombre donné à une URL et va de 0 à 100. Les données se comportent mieux que la précédente variable UEID illimitée dont la moyenne et la médiane sont proches, Ce qui rend une distribution plus "normale" comme nous le verrons plus loin en dessinant un histogramme dans R.
Nous allons faire le même diagramme de division et de densité que Nous l'avons déjà fait et nous verrons les distributions des scores UPA lorsque nous diviserons les données UPA en deux groupes.
# Indiquez les médianes par page de SERP en appelant le service & # 39; tapply & # 39;
> tapply (theResults $ moz_upa, theResults $ rankBin, médian)
Page 1 Page 2
43 39
En résumé, deux distributions très différentes de deux variables d'API Moz. Mais les deux ont montré des différences dans leurs scores entre les pages du SERP et ont fourni des valeurs tangibles (moyennes) avec lesquelles travailler et conseiller les clients sur leur propre référencement ou l’appliquer.
Bien sûr, il ne s'agit que d'un petit échantillon et ne doit pas être pris à la lettre. Mais avec les ressources gratuites de Google et de Moz, vous pouvez maintenant voir comment vous pouvez développer vos propres capacités analytiques pour fonder vos hypothèses au lieu d’accepter la règle. Les facteurs de classement SEO changent tout le temps et disposer de vos propres outils analytiques pour effectuer vos propres tests et expériences vous aidera à avoir une crédibilité et peut-être même une vision unique de quelque chose d'inconnu.
Google vous propose des frais gratuits pour la récupération des résultats de recherche. Si vous avez besoin de plus de 2 500 lignes / mois fournis gratuitement par Moz, vous pouvez acheter de nombreux modes de paiement. MySQL est un téléchargement gratuit et R est également un package gratuit d'analyse statistique (et bien plus encore).
Explorez!