Je vais bientôt commencer un script de rotation de bannière et je reçois un peu perplexe sur la façon de le développer exactement. Supposons qu'un client demande p>
"10.000 impressions dans les 10 prochains jours pour 10 000 $ dollars." P> blockQuote>
Un autre client demande p>
"1000 impressions pour 100 $ dollars." P> blockQuote>
Et une troisième demande p>
"1.000 clics ou 10.000 impressions pour 5 000 $." P> blockQuote>
Comment exactement je déterminer quelle bannière pour montrer sur une page demande? Comment puis-je peser un contre l'autre? Il est clair que la première demande est assez importante, comme je suis censé servir un certain nombre d'impressions dans une fenêtre de temps. p>
Le second client est loin d'être aussi important, car ils ne se soucient pas d'une fenêtre de temps, ils veulent juste un peu de temps visage. p>
Et le dernier client veut placer un dispositif de retenue n ou m sur les impressions / clics, ce qui rend les questions un peu plus difficile. P>
Je suis déjà assez confiant que je vais devoir faire abstraction du poids de ces scénarios pour déterminer qui obtient le plus d'attention. Ma question est quel type d'algorithme est bien entendu possible, et d'autre part comment pourrais-je servir des bannières en poids sans toujours servir la plus importante bannière à chaque demande? P>
4 Réponses :
Utilisez un générateur de nombres aléatoires pour choisir la publicité et le poids avec une priorité pour chaque annonce. Définissez le facteur de pondération plus élevé pour les clients qui souhaitent plus d'impressions ou d'avoir une échéance. Vous pouvez augmenter le facteur de pondération si le temps est presque en hausse. p>
Une fois qu'un client frappe leurs impressions demandées, supprimez la pondération à 0 pour empêcher leur annonce de montrer leur annonce. p>
La pondération par défaut pourrait avoir une pondération de 1 environ, les clients étant autorisés à payer un supplément pour augmenter la priorité (sans leur indiquer la mécanique - la facture comme un placement «premium», etc.). p>
Vous pouvez rendre cela aussi simple ou complexe que vous le souhaitez, mais une version de base inclurait les termes suivants: p>
Les clients de la date limite doivent être plafonnés à 90% de tous les affichages de la page ou de quelque chose pour s'assurer qu'ils n'apparaissent pas les autres. Le dernier terme donne l'urgence de «urgence» pour les clients de la date limite - cela va à l'infini en tant que morts à la date limite, vous devez donc mettre une condition sur le temps restant pour éviter les problèmes avec cela. P>
J'ai envisagé d'ajouter du poids, mais je suis curieux de savoir quel type de calcul / logique serait idéal.
Je pense que la partie prioritaire est évidente, mais l'OP demande à un algorithme de déterminer comment peser.
Une explication plus détaillée a été ajoutée.
La difficulté provient de la contrainte de temps plus que toute autre chose. Je diviserais la priorité de quiconque qui n'a pas spécifié de contrainte de temps de 365 (un an), puis utilisez le temps dans le cadre du facteur de poids. Ainsi: qui devrait vous procurer un indicateur de priorité assez décent. Maintenant, vous ne pouvez pas mélanger et faire correspondre des impressions et des clics pouvez-vous? Ils allaient soit la route d'impression ou la route de clic. Voir comme vous ne pouvez pas contrôler Cliquez, mais vous pouvez contrôler les impressions (au moins, Moreso que des clics), je le peserais selon impressions. p> p>
Je pense que le fait qu'il y a toujours une contrainte de temps implicite est la clé et pourquoi cette réponse fonctionne. Même si le deuxième exemple n'en a pas, il y a vraiment une sorte d'horizon de temps impliqué - soit du client (s'il a fallu 5 ans serait-ils heureux?) Ou par vous (s'ils ne vous ont payé qu'après la dernière impression fait du bon sens d'obtenir ces impressions dans un délai raisonnable).
Cela rendra une transaction à court terme semble bien plus importante que ce n'est en réalité. Vous devez perdre du rendement à long terme.
Une transaction à court terme est plus importante que tout le reste. Surtout s'ils recherchent ce montant pour arriver dans le délai.
Toutes les transactions à court terme ne valent pas la peine. Parfois, une plus longue vous donne plus d'argent, si c'est plus de dollars par impression.
Je aime vraiment l'approche basée sur le temps de AlbertoPL, mais il ne tient pas compte des clics. Il est facile de démontrer des cas pathologiques où les clics sont pertinents: p>
Toute personne raisonnable donner le type de priorité plus élevé en 1 clic. Le calcul est en fait assez trivial. Supposons que votre clic est 100 impressions par clic p>
Client A souhaite 10.000 impressions ou 1 clic, donc nous avons besoin d'un minimum de 100 impressions pour être payé. À un coût de 1 000 $ pour 100 impressions, vous pouvez comprendre que votre client est prêt à payer 10 $ / impression. P> li>
Client B souhaite 10.000 impressions ou 5000 clics. 5000 clics exige 500.000 impressions, nous rencontrerons clairement la marque 10.000 impression avant, donc nous supposons que le client offre vraiment payer 1000 $ pour 10.000 impressions, ou 0,10 $ / impression. P> li> ul>
Nous maximisons les recettes en maximisant notre $$$$$ / impression, si le client A est prioritaire. Utilisons les chiffres fournis dans l'OP: p>
Client 1: p>
Client 2: p>
Client 3: p>
Les clients sont prioritaires en fonction de combien ils paient par jour. P>
J'aime beaucoup cette approche, mais cela devient complexe lorsque vous incluez des taux de visiteurs variables également. Considérons: le client le plus élevé peut vouloir le contrat sur une plus longue période, alors que le paiement payant le plus bas peut avoir une édition courte, mais se traduisent à plus par jour. Si vous pouvez rencontrer les impressions nécessaires à la transaction à court terme, c'est supérieur. Sinon, tu seras mieux avec le long terme.
Microsoft Commerce Server contient un algorithme de NOD (Voir http://msdn.microsoft.com /en-us/library/ms960081%28v=cs.70%29.aspx et http://msdn.microsoft.com/ fr-fr / bibliothèque / ee825423% = 28V cs.10% 29.aspx ) p>
Je l'ai utilisé des versions dérivées de cette formule en 3 serveurs publicitaires différents, qui se sont révélés au travail agréable pour mes conditions. P>
La formule de base concernant votre situation utilise une variable appelée NOD, abréviation de « Besoin de livraison ». À un moment donné, la formule NOD « base » d'une bannière est: p>
NOD = (restants Events / Total des événements Demandés) * (Total Runtime / Restant Runtime) p> blockQuote>
Notez que « Événements » est un terme général, ce qui peut représenter des impressions, les clics, les conversions, etc. en fonction de votre système. P>
Les états de l'équation que toutes les bannières commencent par la valeur initiale de 1,0 à leur vie, parce que (e / e) * (t / t) = 1,0 p>
Un plus élevé que 1 signifie valeur NOD vous êtes derrière votre emploi du temps, tandis qu'un NOD entre 0 et 1 en général signifie que vous avez affiché la bannière « trop vite ». Les valeurs comprises entre 0,9 et 1,2 sont généralement dans la gamme acceptable (ce n'est pas une gamme technique, plutôt une expérience professionnelle). P>
Tant que les ratios de service correspondent à des rapports de durée, les valeurs restent environ 1,0. P>
Pour un espace publicitaire spécifique, l'algorithme vérifie les hochements de toutes les bannières disponibles targettable sur la fente. Supposons que vous avez 3 bannières disponibles sur une fente, avec des valeurs NOD 0,6, 1,35 et 1,05, ce qui ajoute à 3,0. Ensuite, les probabilités relatives de chaque bannière à devenir 20% affichée, 45% et 35% afin [0,6 / (0,6 + 1,35 + 1,05)] = 20% p>
Les utilisations de l'algorithme de distribution de probabilité pondérée, ce qui signifie que même la bannière avec la moindre valeur NOD a la chance d'être affiché. Bien que la formule de base utilise cette approche, les décisions d'affaires me généralement toujours contraints de mettre en œuvre des algorithmes favorisant les valeurs NOD urgentes plus que la formule originale. Alors, je pris les NOD de base et les multipliai avec eux-mêmes. Dans le même exemple, les probabilités deviennent 11%, 55,5% et 33,5% pour. p>
Pour votre état, vous pouvez envisager de modifier la formule un peu pour répondre à vos besoins. Tout d'abord pour être en mesure de comparer les revenus que vous gagnerez en affichant une bannière, vous devez convertir tous les types d'affichage (impression, cliquez sur, action, etc.) à une valeur eCPM commune. Ensuite, vous pouvez utiliser cette eCPM comme un multiplicateur à l'équation d'origine. P>
Calcul eCPM (CPM effectif) pourrait être difficile pour les campagnes ne sont pas encore publiés, dans ce cas, vous devez utiliser des données historiques. P>
Laissez-moi vous expliquer cette partie un peu plus: Lorsque vous essayez de comparer le revenu probable que vous gagnerez par « l'affichage » une seule bannière, vous n'avez pas besoin de comparer les budgets à base d'impression. Pour les budgets en fonction clic, vous devez utiliser la valeur historique du CTR de deviner « combien d'impressions que mon besoin de système pour servir à obtenir X CLiCS ». Un algorithme plus avancé peut utiliser « combien d'impressions que mon besoin de système pour servir à obtenir une campagne dans la catégorie X, dans l'inventaire y ». P>
Ensuite, votre équation finale devient: p>
NOD = eCPM * (restants des événements / Total des événements Demandés) * (Total Durée / restante Runtime) p> blockQuote>
Vous pouvez toujours envisager d'utiliser les pouvoirs de eCPM pour comparer les résultats. Comme ma façon de changer la formule originale pour favoriser des campagnes plus urgentes, vous pourriez favoriser « plus payant » des campagnes. P>
Belle réponse! Avez-vous plus de liens à propos de cela (ou de techniques associées)? Tia
J'ai ajouté des mathématiques supplémentaires à la formule. Notez que quelque chose comme une liste de priorités ou une structure de données de tas peut être utilisé pour obtenir des objectifs similaires.
Je penserais que certaines personnes marketing pourraient avoir une bonne idée des poids - ou au moins certains types comptables pour faire l'algorithme.
@APerkins Je travaille sur une petite équipe de développement. Fondamentalement, c'est juste moi.