Seit Amazon die Bezahlung der KindleUnlimited-Leihen auf gelesene Seiten umgestellt hat, ranken sich zahlreiche Mythen um die Art der Berechnung. Amazon verrät nicht, wie der KENPC zustande kommt – bis auf die Tatsache, dass der Algorithmus angeblich versuche, ein lebensnahes Abbild des Umfangs eines eBooks in Seiten zu bieten.

Aber man kann natürlich versuchen, der Funktionsweise durch Experimente auf die Schliche zu kommen. Damit habe ich in der vergangenen Woche KDP gequält – ich habe nacheinander etwa 15 verschiedene Version desselben E-Books hochgeladen, auf die Freischaltung gewartet und den KENPC abgelesen. Im folgenden beschreibe ich, was ich dabei gelernt habe. Doch zuerst noch ein paar Grundlagen.

Wo sehe ich den KENPC?

Sie finden die Zahl nur bei Ihren bei KDP Select angemeldeten E-Books, indem Sie bei einem Titel im Dashboard auf “Werbung schalten” klicken. Dort steht dann: “Seitenanzahl gemäß KENPC Version 2.0 (Kindle Edition Normalized Page Count): …”

Der KENPC ist nicht auf der Buch-Detailseite zu sehen.

Hat der KENPC etwas mit dem Ranking zu tun?

Nein, die Zahl gelesener Seiten wirkt sich nur auf Ihre Bezahlung aus. Für das Ranking zählt einzig die Ausleihe an sich, unabhängig davon, wie “dick” das E-Book ist.

Hat der KENPC etwas mit der Dateigröße zu tun?

Hat er nicht. Die Dateigröße ist für die Übertragungskosten entscheidend. Doch auch dazu müssen Sie wissen, dass das für Mobi-Dateien nicht gilt. Diese enthalten nämlich zwei Versionen Ihres E-Books, und Amazon berechnet die Übertragungskosten basierend auf der Größe der älteren Variante. Das entspricht meist weniger als der Hälfte der Dateigröße. Leider zeigt das neue KDP-Dashboard die der Berechnung zugrunde liegende Dateigröße nicht mehr an.

Wie Scrivener, Jutoh, Vellum, Papyrus und Calibre sich auf den KENPC auswirken

Vor etwa einer Woche schrieb mir eine Autorin, dass sich die KENPC-Zahl eines Buches erhöht habe, weil sie es im Mobi- statt im ePub-Format hochgeladen hatte. Sollte es tatsächlich so sein, dass Amazon Nutzer des (systemfremden) ePub-Formats benachteiligt und Nutzer der eigenen Mobi-Formats belohnt?

Dieser Frage ging ein Test nach: Ich habe einen identischen Text mit den Programmen Scrivener, Jutoh, Vellum, Papyrus, Word und Calibre auf verschiedenen Wegen ins ePub- und Mobi-Format konvertiert und die daraus entstehende KENPC-Zahl ermittelt. Die Übertragungskosten waren übrigens bei allen Versionen identisch, obwohl die Dateigrößen zwischen 126 Kilobyte (Calibre-ePub) und 2,2 Megabyte (Vellum-Mobi) lagen.

Die Umwandlung von ePub zu Mobi erfolgte in den meisten Fällen mit der aktuellen Version 2.9 von KindleGen (Amazon), außer bei Calibre.

Die Ergebnisse, aufsteigend sortiert nach dem KENPC-Wert:

Programm	Upload als	KENPC
Scrivener	ePub	176
Word	Docx	177
Vellum (Chroma)	ePub	183
HTML/OPF	Mobi	183
Vellum (Meridian)	ePub	183
Vellum (Meridian)	Mobi aus ePub	183
Papyrus 8.08	ePub	185
Papyrus 8.5	ePub	185
Jutoh	ePub	186
Jutoh	Mobi	186
Calibre aus ODT	ePub	186
Calibre aus ePub	Mobi	186
Vellum (Chroma)	Mobi	214
Vellum (Meridian)	Mobi	214

Der Unterschied vom kleinsten zum größten KENPC-Wert macht immerhin knapp 22 Prozent aus. Scrivener liefert den geringsten KENPC-Wert, gemeinsam mit Word. 183-186 KENPC-Seiten scheinen der Normalwert für den umgewandelten Text zu sein. Dabei spielt es keine Rolle, ob man die ePub-Datei direkt hochlädt oder sie erst mit KindleGen umwandelt. Auch die Calibre-eigenen Routinen führen zu ähnlichen Ergebnissen.

Vellum ist ein Ausreißer. Das spannende hier: wandelt man das von Vellum erzeugte ePub mit KindleGen in eine Mobi-Datei um, erhält man dieselbe KENPC-Zahl wie beim ePub. Lässt man allerdings Vellum (das nach eigener Aussage ebenfalls KindleGen nutzt) die Umwandlung übernehmen, erhält man plötzlich ein 17 Prozent größeres E-Book, und auch die Dateigröße vervierfacht sich im Vergleich zum ePub. Das ist – seltsam. Offensichtlich fügt Vellum eine “geheime Zutat” hinzu, die das Mobi-E-Book in Sachen KENPC größer macht. Optisch unterscheiden sich ePub- und Mobi-Version nämlich nicht.

Was tut Vellum da? Das ist schwer zu sagen. Ich habe das Vellum-Mobi mal mit KindleUnpack auseinander genommen. Text und Bilder sind identisch, aber die CSS-Dateien unterscheiden sich. Welcher Parameter genau den Unterschied ausmacht, ließ sich noch nicht ermitteln. Irgendwo wird der Amazon-Algorithmus wohl ins Stolpern kommen.

Was heißt das praktisch? Wenn Sie bisher mit 430.000 Seiten den AllStar-Bonus verpasst haben, müssten sie ihre E-Books nur mit Vellum neu erstellen und kämen dann auf 500.000 Seiten. Bevor Sie nun aber für 200 Dollar die unlimitierte Version von Vellum kaufen – denken Sie daran, was dann passieren wird. Es ist schwer zu sagen, wie groß der Anteil der Vellum-Nutzer unter den KU-Autoren ist. Angenommen, er läge bei weltweit einem Viertel, was vermutlich zu hoch gegriffen ist, denn Vellum ist ja recht teuer. Würde er nun aber auf 100 Prozent steigen, dann wüchse die Zahl gelesener Seiten von einem Monat zum nächsten um 15 Prozent – und die KU-Quote sänke entsprechend.

Ich habe deshalb den Hersteller von Vellum dazu befragt. Die Firma schließt kategorisch aus, dass der Effekt in irgendeiner Weise beabsichtigt ist: “We don’t have any interest in gaming Amazon’s secret calculations, especially since they are subject to change at any moment.” Zudem geben sie den Ball, wohl nicht zu unrecht, zurück an Amazon: ” We would honestly be thrilled if Amazon were able to deliver a page count that is actually normalized” (“wir wären begeistert, wenn Amazon eine Seitenzahl liefern könnte, die wirklich normalisiert ist [das heißt unabhängig von der konkreten Formatierung]”). Ansonsten sind leider Manipulationen über Tricks bei der Formatierung Tür und Tor geöffnet.