Du bist nicht angemeldet.
Ich denke eine solche Kurve ist dann praktisch, wenn man sich an einen Grenzwert herantasten will. Die Kurve macht ja - in Abhaengigkeit eines Parameters - eine mehr oder weniger steilen Anstieg, der dann abflacht.
Anders ausgedrueckt: je geringer ein X-Wert um so steiler steigt der Y-Wert an, je hoeher der X-Wert, um so langsamer steigt die andere. In unserem Fall koennten wir "X" mit der angeforderten Mindestzuschauerzahl uebersetzen, Y waere dann der geforderte Eurobetrag des Vertrages.
Die Formel der Kurve enthaelt ein "G", dass ist der Grenzwert, das maximal erreichbare "Y" der Funktion. In unserem Fall wuerde "G" den Wert einnehmen, den wir als maximal erreichbaren Eurobetrag eines Vertrages ansehen (bspweise 1 Mio pro Spot).
Nehmen wir nun an, dass wir in komplett Deutschland Sendemasten haetten, unsere maximale Reichweite betruege dann 80 Millionen. Ein Spot der 100% MA bei Unterzeichnung fordert, wuerde bei Unterzeichnung umgewandelt in 80 Mio Zuschauer.
Die Formel wuerde also bei x = 80 Mio schauen, was der Y-Wert waere. Dieser waere knapp an dem Grenzwert, also knapp bei 1 Mio.
Ein Spot braechte dort also 1 Mio Euro ein. So - und bis dahin hatten wir ja bei Profit/Penalty Prozentwerte stehen ... wir konnten also dort "modifizieren". 20% Bei Profit wuerde bedeuten, dass wir 20% des erechneten Wertes verlangen, also 200.000.
So ... nun wollen wir aber ja irgendwie was "nachvollziehbares/vergleichbares" in den Datenbanken stehen haben, also mussten dort Eurowerte rein.
Das erzeugt ein Problem: wir haben Eurowerte, statt einen relativen Anteil am Maximum angegeben. Aber halt, haben wir das? Wir haben beides: Eurowerte die sich "schoen lesen" lassen - aber durch ein von uns definiertes "Maximum" auch einen relativen Anteil:
Unser Maximum definiert sich ja bspweise durch "X Euro fuer Gesamtzuschauerzahl" - oder auch "relativX pro 1000 Zuschauer". Wir koennen dadurch beide Werte (Maximum und Angabe in DB) wieder in Relation setzen - und erhalten erneut "Prozente".
Wenn Du also bei Vertrag "Matratzendoktor" stehen hast "profit=400", dann gaebe es einen TKP von 400€ pro 1.000 Zuschauer. Wenn wir festlegen, dass fuer alle Zuschauer Deutschlands maximal 1.000.000 Euro pro Spot gezahlt werden, ergibt dass dort einen TKP von 1.000.000/(80.000.000 / 1.000) = 1.000.000 / 80.000 = 100/8 = 12.5€ pro 1.000 Zuschauer.
Dies wuerde ergeben, dass wir 32 fach ueber dem Maximum liegen ... doof oder?
Hier kommt nun meine Idee dazu: Was ist, wenn wir die Funktion "umkehren" (Reziproke bilden) ? Dann wuerde sich mit hoeherem X der Y-Wert Richtung 0 bewegen - und nach was klingt sowas? Nach einem Einflussfaktor.
Heisst: mit steigender Zuschauerzahl-Anforderung wuerden wir einen Wert zwischen 0 und Grenzwert erhalten, der immer mehr Richtung 0 geht. Deutlicher wird es, wenn wir statt den 80 Millionen Leuten, die 100% als Grenzwert setzen. Wir erhalten also bei geringer Zuschaueranforderung einen Wert von knapp 100%, bei nahezu maximaler hingegen 0%.
Und eben diesen prozentualen Wert koennen wir dann so benutzen (Einflussfaktor von 100% = 1, 75% = 0.75 usw.):
Gewinn pro Spot = DB-Profitwert * Einflussfaktor
Um eine Tabelle mit "Gewinn bei X Zuschauern" zu generieren muss man nun nur noch kennen:
- maximaler Wert (unser Grenzwert)
- den Parameter der den Anstieg der Kurve bestimmt
- den Profit/Straf-Wert aus der Datenbank (der dann den Preis bei einer vergleichbaren Menge darstellt, bspw. 10.000 Zuschauer)
a)
- die Mindestzuschauer aus der Datenbank
- die maximal erreichbaren Zuschauer im Land
oder b)
- die Mindestzuschauer in Relation zur maximal erreichbaren Menge (also "5% von Gesamtdeutschland")
Hoffe ich hab nix uebersehen und es halbwegs "verstaendlich" erklaert.
PS: Interessante Nebenidee dazu: Dadurch dass wir Preise an einem definierten Maximum orientieren, koennten wir auch Spielereignisse haben wie: "Die Werbebranche schluckt - Medien erhöhen Anzeigepreise". Dann wuerde das "Maxmimum" ansteigen, je naeher sich eine Werbung am Maximum orientiert, desto staerker wird sie davon beeinflusst. "Billigwerbung" bleibt davon unbeeindruckt (der laengere Hebel liegt bei kleinen Sendern ja sicher auf seiten der Werbetreibenden).
bye
Ron
Ich sehe da einen Datenbank-Strang am Horizont aufleuchten.
@Prämienkurve
Die macht prinzipiell Sinn.
Soll die an eine fixen Zahl (80 Mio) angehängt werden oder an einer Variable (max. Einwohnerzahl)? Interessant für Mods. (Liechtensteinkarte, Chinakarte etc.)
Wieder neues:
Die Neue Datenbank braucht dann Eure Hilfe! Statt "kryptischer" Informationen wie profit="20" (was sich zu 7,8% umrechnen wuerde) nutzen wir nun profit="600". Hmm, sieht gleich aus - aber halt. Wir hatten intern ja ein paar Multiplikatoren - diese ergaben am Ende "30". Diese 30 wurde nun direkt in den Profit/die Strafe reinmultipliziert . Nun haben wir mit dem Wert "600" eine absolute Aussage: das ist der Tausender-Kontakt-Preis der Werbung - fuer jeden Spot.
Wenn also 3 Spots zu senden sind, und 10% MA gefordert sind, wird bei Unterzeichnung geschaut wieviele Zuschauer man maximal erreichen koennte. Ist dies 100.000, so wuerde der Spot 10.000 Zuschauer erfordern. Bei einem TPK von 600, kaemen da 600*10*3 Euro zustande - also 18.000.
Weiterhin ein Problem bleibt, wie wir mit hoeheren Zuschauerzahlen umgehen, wie also der "Verfall" gemacht wird, denn bei 80 Mio Reichweite, kaemen wir auf 600 * 80.000 * 3 Euro - was ein bisschen viel fuer den Werbespot waere (aber man braeuchte auch wirklich erstmal 8 Mio Zuschauer).
Eventuell muessten wir die Werte mit Anstieg der absoluten Zuschauerzahlen anpassen - hin zu einem "Maximum".
Mir gefaellt dazu folgende Kurve:
http://de.wikipedia.org/wiki/Logistische_Funktion
(nun hab ich sie hier stehen und merk sie mir evtl besser )
Aber eines nach dem Anderen.
Neben diesen Sachen gibt es neue Datenfelder, die positives/negatives Verhalten von Gruppierungen konfigurieren (bspweise bringt ein Werbespot fuer Panzer die Waffenlobby in Extase - die wuerden dann eventuell den naechsten John-Wayne-Film "sponsern" usw.).
Das wichtigste der neuen Datenbank ist aber: sie enthaelt "GUID"s fuer jeden Eintrag. GUID bedeutet "global unique identifier", ist also fuer "uns" eine einzigartige Kennung. Dadurch koennen wir jeden Eintrag eindeutig identifizieren - und referenzieren.
Wenn also dann eine zweite Datenbank (deinname.xml) auftaucht, kann sie anhand dieser GUID einfach bestimmte Werte ueberschreiben. Dir ist also Dein Lieblingsfilm einfach zu teuer? Zack, in die eigene xml rein damit und dort an der Preisschraube drehen.
Beispieldatensatz:
<ad id="fed519fe-c720-46c4-8201-622c244c2000" creator="1234">
<title>
<de>Matratzendoktor</de>
<en></en>
</title>
<description>
<de>Quietscht Ihre Matratze? Rufen Sie den Matratzendoktor. Inklusive Probestunde.</de>
<en></en>
</description>
<conditions min_audience="3.9" min_image="0" target_group="3" />
<data infomercial="0" quality="0" repetitions="3" duration="3" fix_price="0" profit="450" penalty="330" />
</ad>
Hier erkennt man auch gut, dass das Lokalisieren in einer eigenen datenbank.xml stattfinden koennte (gleiche Referenz, aber <en>Doctor Sleep-Well</en>).
bye
Ron
Die naechste Version wird wohl schon die neue Fassung der Datenbank enthalten.
Da wir da nicht nur beim Einlesen Sachen aendern, sondern die enthaltenen "Werte" auch neuformatiert werden (statt 0-255 wird es dann 0-100, bzw 1.0 wenn es sich um Modifikatoren handelt), kann es sein, dass wir irgendwas uebersehen und damit Endwerte falsch berechnet werden.
Durch mehrfaches Runden (die neue Datenbank muss ja "alterWert durch 255" rechnen und speichert dann die Ganzzahl) wird es zu kleinen Abweichungen fuehren (Sachen bringen 0.05% weniger MA, der Preis ist durch das "Schoenrechnen" 1000 Euro mehr usw.).
Hoffe wir bekommen dass die Tage alles in eine lauffaehige Fassung.
bye
Ron