Bekijk alle posts

Ik heb die mail in november 2010 gehad (dat is ook de datum van genoemde blogpost). Maar ik heb mij dan aangemeld op de AdSense blog zodat je dit soort blogposts direct in je mailbox ontvangt.

Ik weet iig dat als ik het ga aanpassen dat ik veel inkomsten zal mislopen.

Dat dacht ik ook van te voren. Desondanks vorig jaar toch aangepast en wat bleek? CTR en inkomsten namen juist iets toe. :)

Letwel dat je tussen een game en een advertentie in die 150px ruimte geen tekst of andere links zet.

Dus je doet bijvoorbeeld:

[advertentie]

[150px witruimte]

[game]

[150px witruimte]

[advertentie]


Gevolg is dat mensen als ze klaar zijn met het spel naar boven of naar beneden moeten scrollen om andere content te zien. En laat nou het eerste wat ze te zien krijgen en waar ze op kunnen klikken een advertentie zijn. En dat doen ze dan dus ook. Althans, op mijn game websites wel.

Je zou ook nog kunnen splittesten met juist nog meer dan 150px witruimte. Probeer het bijvoorbeeld eens met 250px.

Ik zou ook voor broodjeaapvla.com kiezen.

Ik zou echter tevens kijken of en hoeveel er gezocht wordt op "broodje" + "aap" + "een derde zoekwoord" en dan voor een combinatie van drie woorden gaan waar het meest op gezocht wordt (en het domein vrij is).

Ik moet voor bezoekers uit de VS een andere pagina (met telefoonnummer van helpdesk laten zien).

Wie kent een goede/betrouwbare API die op basis van IP adres het land van een bezoeker teruggeeft?

Nu heb ik er via Google al een aantal gevonden. Bijvoorbeeld (Log in om link te zien!) Maar ik kom er zoveel tegen dat ik door de bomen het bos niet meer zie. Zit er veel verschil tussen de verschillende API's?

In dit geval is het (gratis) nummer van de helpdesk alleen beschikbaar voor de VS. Bezoekers uit de VS moeten nadat ze op een 'download' link hebben geklikt een pagina te zien krijgen met daarin o.a. de tekst dat als het downloaden of installeren niet lukt men het betreffende nummer kan bellen. Maar daar heb ik dus een betrouwbare GEO API voor nodig.

Misschien kan je dit gebruiken: php.net/manual/en/book.geoip.php

Heb ik naar gekeken, maar dan moet ik een package installeren en configureren en iedere maand de database updaten. Met name het installeren en configureren van een package is absoluut niet mijn ding. Aan de andere kant zou ik dat ook door iemand ander kunnen laten doen. Maar ik ben eigenlijk zoekende naar een makkelijkere oplossing.

Google maps heeft hiervoor ook een api beschikbaar.. Wel beetje afhankelijk hoeveel calls je afhandeld.. aangezien dit wel gelimiteerd is.

Dat was ook mijn eerste gedachte, maar op (Log in om link te zien!) lees ik onderstaande:

Detecting the User's Location Currently, several ways exist to detect the user's location within a browser. None of these methods are part of the Google Maps API; instead, they are common industry standards.

Of zie ik iets over het hoofd?

Ik denk dat ik toch maar hostip.info of ipinfodb.com ga gebruiken.

Is inderdaad altijd al zo geweest. Inkomsten januari ontvang je eind februari. Inkomsten februari ontvang je eind maart. Etc. etc.

Je kunt dit terugzien in je betalingsoverzicht.

Wat nieuw is -ik geloof sinds een maand of 2- dat je te duidelijk te zien krijgt dat inkomsten van -in dit geval- april op 10 mei definitief worden. De betaling van april krijg je dan rond 25 mei. En dat is dus altijd al zo geweest. Ook in jouw account.

Het is nog nooit zo geweest dat je inkomsten van bijvoorbeeld april al begin mei op je rekening krijgt.

Nee, oke. Maar ik krijg mijn Adsense normaal de maand erna voor het einde van de maand. Nu voor het eerst dus niet.

Klopt, normaal is het rond de 27e. Bij is het nu ook nog niet binnen. Ik zie wel in mijn betalingsoverzicht dat het op 27 april is verzonden. Zal dan denk maandag worden bijgeschreven.

Overigens was afgelopen vrijdag eenmalig een 'bank holiday' in Ierland i.v.m. het trouwfeestje. Dus wellicht dat het daardoor (i.c.m. weekend) het iets later komt dan normaal.

Pas maar op, voordat Stichting Brein ineens achter je aan zit.

Brein kan niemand iets maken als het gaat om het downloaden van muziek aangezien het downloaden van muziek in Nederland gewoon legaal is.

@Erwin ik lees nog steeds nergens duidelijk dat er echt dubbel betaald moet worden.

Een aantal jaar geleden was het zo dat radiostations per luisteraar moeten betalen. Wat betreft internet moest men per opgezette stream (dus per luisteraar) betalen ongeacht op welke website die stream eventueel ge-embed was.

Als dit nu nog steeds het geval is (en daar lijkt het wel op) dan gaat Buma inderdaad dubbel ontvangen. Tenzij de radiostations ofwel eigenaren van de streams stoppen met het betalen voor luisteraars in het geval dat het om luisteraars via een stream op een site van derden gaat.

Maar dat lijkt mij sterk, want dan is deze maatregels van Buma helemaal zinloos en onnodig ingewikkeld. I.p.v. dat Buma 100% van de heffingen van radiostation X ontvangt zou het dan nu bijvoorbeeld 70% van radiostation X moeten ontvangen, 2% website derde partij 1, 2% website derde partij 2 etc. etc.

--EDIT -> aanvulling op mijn vorige reactie--
Ik had niet goed gelezen. Bram S. schreef het ook al:

er wordt door de radiostations betaald voor het aantal streamstarts/luisteraars

Overigens weet ik dat dit iniedergeval een aantal jaar geleden zo was (radiostations per luisteraar moesten betalen, ook op het internet) omdat ik destijds bij een mobile media bedrijf (Tutch) werkte en veel contact had met bepaalde radiostations en Buma.

Buma/Stemra maakt onderscheid tussen bronsites en doelsites. De website van de eerste aanbieder wordt de bronsite genoemd. Dit is meestal de maker van de orginele R/TV zender. De website van een externe persoon of partij die de R/TV zender opnieuw beschikbaar stelt, wordt een doelsite genoemd, zoals bijvoorbeeld radioportals. Het basistarief voor het opnieuw aanbieden van 2 * of meer R/TV zenders op doelsites bedraagt 10% van de netto gegenereerde inkomsten met de website

Dan lijkt het mij dat de situatie inderdaad anders is dan in het verleden. Dus op het eerste gezicht lijkt er geen sprake te zijn van dubbel betalen.

Alhoewel uit bovenstaande tekst ook weer niet eenduidig blijkt of een radiostation wel/niet ook nog eens per luisteraar moet betalen.