Hey plugin builders, Jake here 
How many applications are actively using your plugin?
I found myself asking this question after I started building my own plugins.
Getting that first subscriber notification felt electrifying!
Then a month later I got paid a lot less than I was expecting, because the user had unsubscribed.
Then I got another subscriber (yay!) and lost them too (
).
The uses and installs numbers just weren’t giving me any clarity on how many apps were actually using my plugin… So I decided to take a stab at doing my own analytics.
With that, I created PluginPulse.
What is it?
Similar to Google Analytics and other analytics software, PluginPulse works with a simple code snippet in your plugin’s shared headers.
When a user of your plugin visits their application in version-test mode, it sends a tracking event with the plugin ID and a hashed version of their app ID.
What does it cost?
It’s free to create an account so you can add your plugins and generate the code snippets and only pay when you’re ready to receive events. Even though it’s a one time payment, it comes with updates and continued support!
More details on pricing can be found here
Excited to hear your thoughts so hit me up with any questions you have!
5 Likes
My first instinct was: I love the idea.
The second was: is that… a good idea?
Is there any language in Bubble’s agreements that a plugin builder shouldn’t do tracking?
I’m guessing there are plugins in the wild already doing tracking.
2 Likes
Every Z*roqode plugin I’ve seen does tracking, saving your app ID, what device/browser your user is on, if its test vs live, etc. Bubble does say to put tracking code 
3 Likes
that’s tracking code of analytics and similar things that the plugin is integrating. it’s the plugin’s user tracking code, not the plugin builder tracking code.
I suppose there is not a term forbidding this, but at the very least it should be disclosed to let the plugin user aware in case it needs to be reported in the privacy terms of the app
4 Likes
Great question!
I went through their terms and there isn’t anything explicitly against tracking plugin usage.
To be safe, I did reach out to them, explaining my product and how it works and they didn’t have any concerns with it.
I had hoped to include a feature where you could authenticate (securely, of course) with your Bubble credentials and I would scrape the Marketplace page and pull your transactional data automatically, but they said no to that one.
That’s a big reason why I decided to hash the app ID on the client before sending it, since it’s the only identifiable datapoint coming from the end plugin user.
This is my hashing code, for transparency:
// Function to convert ArrayBuffer to hex string
function bufferToHex(buffer) {
return Array.from(new Uint8Array(buffer))
.map((b) => b.toString(16).padStart(2, "0"))
.join("")
.substring(0, 12);
}
// Function to hash app_id using SHA-256
export async function hashAppId(appId) {
const encoder = new TextEncoder();
const data = encoder.encode(appId);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);
return bufferToHex(hashBuffer);
}
And this is the events table:
yeah but sometimes an ip address is considered personal information so a request from the client to your server is something that the app owner needs to be aware of.
of course I’m not an expert of privacy matters, I like to build apps (that is much more easy than dealing with laws 
)
since this is tracking the use of element plugins you can provide a snippet to use in the preview. this way the app user is not involved, but I’m not sure what info you have available in the sandboxed preview iframe
1 Like
Yeah, I know what you mean!
From my understanding of GDPR (which is likely incorrect 
), as long as an individual can’t be identified by the information, then it’s ok.
So an IP address is a no-no if I can tie it to a specific person (with an email address or name for example).
