• UTM Tracking Parameters


    The analytics data we tracked so far was pretty minimalistic. While we have added some UTM tags in the past, the usage of them was inconsistent to say the least.

    So, when we set out to improve the way we display feature hints and generally experiment a bit more with other things from inside the plugin, I wanted to make sure that we also get some usable data about those links.

    If you don’t know already what UTM parameters are, you can find an introduction in Google’s own Analytics Help Center to get you started.

    Setting some Goals

    First things first: I googled about UTM best practices and looked at what other plugins are doing and as with many things, there are a lot of different ways how you can go about this, none necessarily more correct than the other.

    But I needed to decide what’s best for us, so I did what I often do in such situations: I wrote down a list of the most important questions that I want answered.

    With these goals in mind, I started looking for the technical implementation.

    Next: Use a Link shortener

    In the past, when we added UTM parameters to links, we hardcoded them into our plugin code, readme files or wherever else we put them. While this kind of worked, it made every change dependent on us pushing a new version out and then also wait until people upgraded to that new version. This can take some time (or in some cases never happen) and makes the data unreliable.

    The solution to this is using a link shortener, where we can define shortlinks like go.picu.io/some-link which then get redirected to the proper URL including all of the needed UTM tags. These shortlinks are then place wherever we need a link to our website. We decided to use the open source and self-hosted “YOURLS” but you could also use a service like bitly and get the same result.

    Now, if we want to change anything in regards to those UTM tags in the future, maybe rename a tag or even add a new one, we can simply update the target URLs in our shortener and those changes will be live immediately. No need to push any code or wait for any upgrades to happen.

    UTM Strategy

    After I wrote some of my initial ideas down, a good friend – who happens to be a Digital Analytics Pro and eats this stuff for breakfast – sat down with me and helped me a lot to unwhirl my own thoughts and get this started. Thanks Boris!

    As said above, there are various ways to structure your UTM tags, and those can go from pretty simplistic all the way up to very, very complicated setups. Our old setup was too minimalistic, but I also don’t wan’t to overcomplicate things, so we needed to find something in the middle.

    As a baseline, here’s what we did in the past, with our old “setup”:

    UTM parameterDescription
    utm_sourcepicu_plugin – for all in-plugin links
    wordpress.org – for links coming from the plugin repository (I think these are added by default by wp.org?)
    utm_mediumpro_hints – all hints we placed inside the plugin (things like “Did you know you could do X and Y with picu Pro?”)
    pro_metabox – our main “banner” that we show in the metabox of the wp editor screens

    And that was about it. While this gave us some data, there was a lot to be desired as well.

    For example, we could see if pro_hints where clicked, but could not differentiate between them.

    So, without further ado, here’s what we ended up with, at least to begin with:

    UTM parameterDescription
    utm_sourceWhere is this link coming from, at this point we’ll mostly have:

    picu_plugin – for all in-plugin links
    wordpress.org – for links coming from the plugin repository
    email – our own newsletter 
    utm_mediumWe use this for the type of link. This will certainly evolve, but so far we use:

    feature_hints – all feature hints inside the plugin
    settings_banner – banners on the picu settings page for pro features
    settings_docs – help links from settings to our documentation
    pro_metabox – our main “banner” that we show in the metabox of the wp editor screens
    utm_campaignA descriptive title for the campaign, for easier handling this will often be the same as the slug of the shortlink, for example:

    more-control – is used as the campaign for the shortlink go.picu.io/more-control
    utm_termThe screen this link was placed on in the plugin, like:

    screen_edit-collection – edit screen of our collections
    screen_picu-settings – our picu settings screen

    (not used so far, but might be for things like an A/B test or if we want to differentiate between a link on an image and one on a text etc.)

    This new structure has been live for two days only, so it’s too early to tell if it works as I hope or what adjustments we need to make, but I’m optimistic and look forward to getting some more insights.

    If you use a similar structure yourself (or even a completely different one), or have anything else to add, please let me know!

  • Improving “+ Add Client”


    I worked on improving a particular function on the collection edit screen: Adding a client to an open collection.

    This is what the previous modal looked like:

    This is the new version:

    I updated this dialog with the following features:

    • Adding a name field. (Which is already possible for clients themselves in the front end, so this establishes feature parity)
    • Making the sending of the email optional. (As some clients prefer to send collection links through other channels, it makes sense to make this optional here as well.)

    I also made the checkbox somewhat dynamic, by only allowing it to be checked, if the email field is not empty:

    (Could be improved by checking if the input is actually a valid email address.)

  • E-Commerce Survey


    Yesterday we sent out a newsletter asking for feedback from our users about e-commerce integration into picu.

    Selling images directly through picu, as part of the proofing workflow, has been one of the most requested features and we feel like it is finally time to get to work on it.

    But we want to make educated decisions on which features make the most sense for the majority of our users – hence, the survey.

    So if you are a picu user and have a specific workflow in mind, please fill out the survey, and let us know! Cheers!

    PS: Quick note, because it came up in some of the survey replies already: The existing, easy-to-use proofing workflow will always be the core of picu. E-commerce will extend the workflow for photographers who need/want it. If proofing is everything you need, skip right along.

  • Email required setting update


    We had another discussion about the email required setting, see my last update about this issue.

    We decided to simply describe what the setting does – as it should be.

    But we opted to also include a help link to our docs page, where we provide more information about the whole registration process.

    I think this makes a lot of sense, and we should have provided that info from the beginning to make it clearer, especially to existing picu users, how the new process works.

    Here’s the final setting, which we will ship, hopefully later today:

  • Email required or optional?


    With our last release we added a registration form, so that clients could identify themselves before making a selection. This enables the photographer to share the same link with multiple clients – or even allow the client to share the link with colleagues, etc.

    We also added a setting whether entering an email address was required during registration. Unfortunately the setting and the registration form were somewhat confusing.

    Many users thought that this option would turn the registration feature on or off. What made this additionally confusing was the fact, that the registration form did not reflect the setting.

    The previous setting:

    The previous registration form:

    I updated the setting to

    • make it clear, that it only controls, whether an email address is required during registration
    • I added a note, explaining that a confirmation email is always sent if an email address is entered – whether the field is required or not.

    The updated setting:

    This might not be final, but I think it is already much clearer than the previous version.

    The updated registration form (email not required):

    I made it clear, that the email field was optional and updated the intro paragraph to not explicitly mention the email anymore.

  • Pro banner


    We still use this static banner in a couple of places and from the feedback we got, we should definitely make it more concise and to the point. So…


    I updated the wording, and also made two versions, one with a light background color, so it might fit in better with our other, new banners.



    • I figured the logo is not really needed and takes way to much space
    • Turned the text into a list and it is much more readable/scannable now
    • I still like to keep the social proof, and the stars are a nice eye-catcher

    I’ll let them sit for a bit, before making a decision.

    Update: And yes, there is a typo! Glad to have Claudio, who will surely catch those, before we ship the banners!

  • Goals for our new website


    As requested by Florian, let’s also share some of the progress we’re making on the marketing & design side of things, first and foremost towards our new website.

    The original site was launched 8+ years ago and only got some minor changes since, so by the end of last year I decided it’s time to give it some love, scrap it altogether and start anew.

    In this first post I want to share the overall goals I initially set for the redesign as well as some early screenshots:

    1. Modern, professional & friendly look:
      The old site feels more and more out of date and even a little unprofessional in some places.
    2. Make it easy and fun to edit content:
      Because the harder it is for us to write on it, the less we actually do. This should also make it a lot easier to experiment, add new landing pages fast or even do some A/B testing in the future (which would have been a total pain to do right now).
    3. Make it a little more personal:
      I just really like it if I see some personality on any website and it’s a huge turnoff for me, if I can’t see who’s behind a company.
    4. Conversion Tracking:
      I joked in a discussion at WordCamp Europe that it feels like we don’t even throw things at the wall and see what sticks, but even worse: we throw it behind our backs without even looking what sticks. While this is certainly a little exaggerated, it is definitely something we need to improve, and the new site is the perfect opportunity to finally get at it.

    Of course, there lots of other things and smaller “sub-goals”, like adding more social proof, or making it performant or as accessible as possible, but those are basic principles or supporting the above goals.

    Without further ado. Here’s some teaser screenshots, I’ll share some more on the thinking behind it all very soon.

  • Continuing with improving the in-plugin banners, I am today looking at the ones we display on our collection edit screen.

    So far they look like this (red highlight added to make the position obvious):

    We randomly display different Pro features here:

    I quite like those, they are very unobtrusive and also kind of playful with the eyes.

    On the other hand, they should probably be more obvious/in your face, to do their job better. (We still need to introduce better tracking to draw any conclusions on how good they actually work. Claudio will surely have to say more about that in a future post.)

    Current ideas:


    • Give it a little more room to breathe
    • Update the wording, state how a feature can directly benefit the photographer
    • Use different emojis to keep the “playfulness” but giving it more variety
    • Add the Pro icon we already use in the new settings banners


    • Add the same background and link color, as in the settings

    I think I am leaning towards #1. You?


    The improved wording and new emojis:

    Still a work in progress…

  • How picu settings work


    I was asked by Marc about how our settings work. Well, his original question was if we use React, but since we don’t and since I have this new blog here, I thought I just might try to give a very basic overview of how we implemented it. Maybe this is helpful to someone.

    We define all of our settings using one big $settings array.

    We can add new settings pages like this:

    $settings['general'] = [
        'title' => __( 'General', 'picu' ),
        'description' => __( 'General picu settings.', 'picu' ),
        'icon' => '<svg>…</svg>',
        'priority' => 1

    We can add individual settings like this:

    $settings['general']['settings'] => [
        'random_slugs' => [
        'type' => 'checkbox',
        'label' => __( 'Use random URLs for picu collections', 'picu' ),
        'description' => __( 'Disable, to use the WordPress default, generating the slug from the title.', 'picu' ),
        'default' => 'on'

    This is what it looks like in the WordPress Admin:

    There is a filter in place, which we use add settings from our Pro plugin. (Other developers could easily add their own settings as well, btw.)

    We iterate through this array to register all of the submenu pages and individual settings.

    We also have a couple of helper functions in place, which render basic setting types, such as checkboxes and text fields.

    But it is also possible to use a custom function for more complex settings by using the type of html and then adding the callback function via output:

    $settings['design-appearance']['settings'] => [
        'theme' => [
            'type' => 'html',
            'output' => 'picu_settings_theme',
            'label' => __( 'Theme', 'picu' ),
            'default' => 'dark'

    This is what the theme settings looks like:

    What I love most about this system is how easy it is to add new settings.

  • Shimmer effect


    Not sure this will stay in, but I think this is a fun little effect, which adds a tiny eye-catcher to the Pro icon:

    It has more pause in between the effect in the actual implementation, than the gif above.

    Created entirely with CSS:

    .picu-pro-box__icon {
        background: linear-gradient(-45deg, #027791 40%, #f2fafb 50%, #027791 60%);
        background-size: 300%;
        background-position-x: 100%;
        animation: shimmer 5s infinite linear;
        animation-delay: 3s;
    @keyframes shimmer {
        12%, 100% {
            background-position-x: 0%
        0% {}
        10% {}
  • Today’s banner drafts


    And these are all the different settings banners, I came up with today. Final wording and images tbd, of course.





  • Improving in-plugin banners


    Today I am working on our static, in-plugin banner, we are currently displaying at the side of the settings page. I am in the process of changing it to an inline, “context aware” banner, which will contain much more relevant (and helpful) information.



    The goal is to raise the awareness of how Pro can help the photographer in the context they are right now.

    🙌 Thanks Matt, for the input on this!

  • Hello world!


    Welcome to the picu Dev Log.